On Tue, 10 Mar 2020, Reuben Farrelly wrote:
I'd like to convert an existing, working configuration from VTI to XFRM
support. But obviously I am missing something as it doesn't seem to be a
straightforward change.
My existing config looks like this:
conn router-2.reub.net-ipv4
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
mark=1/0xffffffff
vti-interface=vti-1
leftvti=192.168.6.1/30
That all works just fine. It is entirely route based, whatever traffic is
routed down the link is encrypted, and it works as expected.
However to convert over to use xfrm I changed the following:
- change leftvti= to be leftinterface-ip=
- change vti-interface= to ipsec-interface=
Yes, but it has to be either "yes" (meaning 1) or a number.
- remove mark= (is this even necessary for vti anymore?)
It was needed for VTI but not for XFRMi. We should probably not allow it
with ipsec-interface= set.
asynchronous network error report on eth0 (172.105.178.21:500) for message to
1.144.144.75 port 500, complainant 172.105.178.21: No route to host [errno
113, origin ICMP type 3 code 1 (not authenticated)]
Mar 10 11:27:35.161044: "router-2.reub.net-ipv4"[1] 1.144.144.75 #2:
liveness_check - peer 1.144.144.75 has not responded in 59 seconds, with a
timeout of 45, taking action:clear
This looks like an imploded route that caused IKE traffic to fail?
Mar 10 11:27:35.185931: "router-2.reub.net-ipv4"[1] 1.144.144.75:
unroute-client output: leftsubet == rightsubnet = 0.0.0.0/0 can not add route
this is fine. you need to do the routing into the ipsec interface for
0/0 to 0/0 tunnels.
Mar 10 11:25:50.161136: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1: received
unsupported NOTIFY v2N_SET_WINDOW_SIZE
You can ignore that.
Mar 10 11:25:50.161141: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1: received
unsupported NOTIFY v2N_NON_FIRST_FRAGMENTS_ALSO
And that.
Mar 10 11:25:50.202585: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
route-client output: leftsubet == rightsubnet = 0.0.0.0/0 can not add route
This is okay, you need to route manually because only you know what
traffic should go into the ipsecX interface.
Mar 10 11:25:50.210179: "router-2.reub.net-ipv4"[1] 1.144.144.75 #1:
route-client output: /usr/libexec/ipsec/_updown.netkey: doroute "ip -4 rule
add prio 100 to 0.0.0.0/0 fwmark 1/0xffffffff lookup 50" failed (RTNETLINK
answers: Operation not supported)
This seems to indicate you mistakenly used the mark= option with XFRMi.
Mar 10 11:25:53.296238: "router-2.reub.net-ipv4"[1] 1.144.144.75 #3: ERROR:
asynchronous network error report on eth0 (172.105.178.21:500) for message to
1.144.144.75 port 500, complainant 172.105.178.21: No route to host [errno
113, origin ICMP type 3 code 1 (not authenticated)]
Looks like route implostion that caused IKE traffic to fail? Due to some
weird or bogus route?
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
