Open wmasilva opened 6 days ago
The log contains:
Oct 18 09:52:07.300108: | found "tunnel2-nat"
which doesn't appear in the config?
The log contains:
Oct 18 09:52:07.300108: | found "tunnel2-nat"
which doesn't appear in the config?
Hi @cagney , i update the config.
@wmasilva tks It shouldn't matter but sometimes a problem can be traced back to the connections and how they are ordered.
Oct 18 09:52:07.299981: "tunnel8"[2] 6.149.27.119 #3: the peer proposed: 192.168.20.0/24===192.168.20.100/32
Oct 18 09:52:07.299989: | looking for 192.168.20.0/24===192.168.20.100/32
but then:
Oct 18 09:52:07.299994: | concrete checking against sr#0 0.0.0.0/0 -> 192.168.20.100/32
Oct 18 09:52:07.300010: | fc_try: looking at 0.0.0.0/0===192.168.20.100/32
i.e., it's lost one end's selector, likely using spd.client instead of the proposed client
The failing log has:
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119 #5: responding to Main Mode from unknown peer 6.149.27.119:500
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119 #5: sent Main Mode R1
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119 #5: sent Main Mode R2
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119 #5: Peer ID is ID_IPV4_ADDR: '192.168.1.60'
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119 #5: switched to "tunnel8"[6] 6.149.27.119
Oct 17 10:15:01 sol1 pluto[855951]: "tunnel8"[5] 6.149.27.119: deleting connection instance with peer 6.149.27.119
which is interesting - the Peer ID is for the client. Does the successful log look the same?
Hi @cagney,
It looks the same...
Oct 25 09:29:26.106120: "tunnel8"[1] 6.149.27.119 #3: responding to Main Mode from unknown peer 6.149.27.119:500
Oct 25 09:29:26.106195: "tunnel8"[1] 6.149.27.119 #3: sent Main Mode R1
Oct 25 09:29:26.148094: "tunnel8"[1] 6.149.27.119 #3: sent Main Mode R2
Oct 25 09:29:26.185039: "tunnel8"[1] 6.149.27.119 #3: Peer ID is ID_IPV4_ADDR: '192.168.1.60'
Oct 25 09:29:26.185079: "tunnel8"[1] 6.149.27.119 #3: switched to "tunnel8"[2] 6.149.27.119
Oct 25 09:29:26.185083: "tunnel8"[1] 6.149.27.119: deleting connection instance with peer 6.149.27.119
Attach a full log with plutodebug=all, when connecting with previous version 5.0.
Thanks! The old log has this:
Oct 25 09:11:13.420007: | concluding with d = none
Oct 25 09:11:13.420009: | using something (we hope the IP we or they are NAT'ed to) for transport mode connection "tunnel8"[2] 6.149.27.119
Oct 25 09:11:13.420013: | "tunnel8"[2] 6.149.27.119: addref @0x55aede9a7058(1->2) "tunnel8"[2] 6.149.27.119: (quick_inI1_outR1_tail() +1110 programs/pluto/ikev1_quick.c)
which was rewritten by 7e82ade3b90f5db636d550b2bb04ddd66686f8de vis:
- if (nat_traversal_detected(p1st) &&
- !(p1st->st_policy & POLICY_TUNNEL) &&
- p == NULL) {
+ /*
+ * For instance: ikev1-l2tp-02 and ikev1-nat-transport-02.
+ */
+ if (p == NULL &&
+ c->config->child_sa.encap_mode == ENCAP_MODE_TRANSPORT &&
+ nat_traversal_detected(p1st)) {
p = c;
- connection_buf cib;
- dbg("using something (we hope the IP we or they are NAT'ed to) for transport mode connection "PRI_CONNECTION"",
- pri_connection(p, &cib));
+ pdbg(p1st->logger, "using existing connection; nothing better and current is NAT'ed and transport mode");
+ }
the replaced logic !(p1st->st_policy & POLICY_TUNNEL)
was the old way of testing for TRANSPORT mode. The config has:
tunnel8
has type=tunnel
tunnel2
has type=transport
suggesting this was stumbling on when it shouldn't. The find-a-better connection code should have found tunnel8[2]
.
More reading.
The code in ikev1_quick.c isn't written to handle "narrowing" - it uses selector_range_eq_selector_range()
when looking for a better connection (IKEv2 uses selector_in_selector()
). This suggests:
What happened?
after update from version 5.0 to version 5.1 cannot establish connection with the error message:
cannot respond to IPsec SA request because no connection is known for 192.168.20.0/24===82.100.127.28[@xauth.mad,MS+XS+S=C]...6.149.27.119[192.168.1.60,+MC+XC+S=C]===192.168.20.2/32
Discussed in the mailing list: https://lists.libreswan.org/archives/list/swan@lists.libreswan.org/thread/SQ2TXV27BNYLQTSPDT77LA2XMOH455BY/
Your configuration
Relevant log output