Can you change auto=ondemand to auto=start ? On demand is a bit odd for “all traffic”.
Perhaps you also want to reduce the 0.0.0.0/0 to the range you want to talk to at the server end. Eg in both server and client config. Sent using a virtual keyboard on a phone > On Oct 13, 2021, at 12:16, Phil Nightowl <[email protected]> wrote: > > >> >>> A brief summary: >>> >>> server --------------- NAT1 -------- internet --- NAT2 ------ roadwarrior >>> 172.16.0.129 172.16.0.254/1.2.3.4 10.0.0.x 10.0.0.y >>> >>> >> It means your subnets/IPs are not matching. The easiest IKEv2 solution >> is for the server to give the roadwarrior an IP to use. > > Adjusted configuration accordingly. The configs are now: > >>> Server (responder): >>> ------------------- > conn roadw > type=tunnel > left=%defaultroute > leftid=@server > leftsubnet=0.0.0.0/0 > right=%any > rightid=@roadw > rightsubnet=vhost:%priv,%no > rightaddresspool=100.64.0.1-100.64.0.10 > narrowing=yes > auto=add > ikev2=insist > authby=secret > pfs=yes > aggressive=no > salifetime=1h > negotiationshunt=hold > failureshunt=drop > rekey=no > > >>> Roadwarrior (initiator): >>> ------------------------ > conn server > left=%defaultroute > leftid=@roadw > right=1.2.3.4 > rightid=@server > ikev2=insist > auto=ondemand > authby=secret > pfs=yes > aggressive=no > salifetime=1h > negotiationshunt=hold > failureshunt=drop > narrowing=yes > leftsubnet=0.0.0.0/0 > rightsubnet=0.0.0.0/0 > > > However, the resulting behaviour is absolutely puzzling me. There is not a > single ipsec packet on the wire. On the roadwarrior (initiator), I can read: > > pluto[13792]: | kernel_process_msg_cb process netlink message > pluto[13792]: | netlink_get: XFRM_MSG_ACQUIRE message > pluto[13792]: | xfrm netlink msg len 376 > pluto[13792]: | xfrm acquire rtattribute type 5 > pluto[13792]: | xfrm acquire rtattribute type 16 > pluto[13792]: | add bare shunt 0x563e26c06018 10.0.0.13/32:40693 --17--> > 1.2.3.4/32:1025 => %hold 0 %acquire-netlink > pluto[13792]: initiate on demand from 10.0.0.13:40693 to 1.2.3.4:1025 > proto=17 because: acquire > pluto[13792]: | find_connection: looking for policy for connection: > 10.0.0.13:17/40693 -> 1.2.3.4:17/1025 > pluto[13792]: | find_connection: conn "server" has compatible peers: > 0.0.0.0/0 -> 0.0.0.0/0 [pri: 8] > pluto[13792]: | find_connection: first OK "server" [pri:8]{0x563e26c04ee8} > (child none) > pluto[13792]: | find_connection: concluding with "server" > [pri:8]{0x563e26c04ee8} kind=CK_TEMPLATE > pluto[13792]: cannot initiate connection for packet 10.0.0.13:40693 -> > 1.2.3.4:1025 proto=17 - template conn > pluto[13792]: | initiate on demand using RSASIG from 10.0.0.13 to 1.2.3.4 > pluto[13792]: | timer_event_cb: processing event@0x563e26bef708 > pluto[13792]: | handling event EVENT_SHUNT_SCAN > pluto[13792]: | expiring aged bare shunts from shunt table > pluto[13792]: | keeping recent bare shunt 0x563e26c06018 10.0.0.13/32:40693 > --17--> 1.2.3.4/32:1025 => %hold 0 %acquire-netlink > pluto[13792]: | event_schedule: new EVENT_SHUNT_SCAN-pe@0x563e26c09298 > pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds > pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe@0x563e26bef708 > pluto[13792]: | timer_event_cb: processing event@0x563e26c09298 > pluto[13792]: | handling event EVENT_SHUNT_SCAN > pluto[13792]: | expiring aged bare shunts from shunt table > pluto[13792]: | keeping recent bare shunt 0x563e26c06018 10.0.0.13/32:40693 > --17--> 1.2.3.4/32:1025 => %hold 0 %acquire-netlink > pluto[13792]: | event_schedule: new EVENT_SHUNT_SCAN-pe@0x563e26c09988 > pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds > pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe@0x563e26c09298 > pluto[13792]: | kernel_process_msg_cb process netlink message > pluto[13792]: | netlink_get: XFRM_MSG_ACQUIRE message > pluto[13792]: | xfrm netlink msg len 376 > pluto[13792]: | xfrm acquire rtattribute type 5 > pluto[13792]: | xfrm acquire rtattribute type 16 > pluto[13792]: | add bare shunt 0x563e26c05e18 10.0.0.13/32:57994 --6--> > 104.21.22.28/32:443 => %hold 0 %acquire-netlink > pluto[13792]: initiate on demand from 10.0.0.13:57994 to 104.21.22.28:443 > proto=6 because: acquire > pluto[13792]: | find_connection: looking for policy for connection: > 10.0.0.13:6/57994 -> 104.21.22.28:6/443 > pluto[13792]: | find_connection: conn "server" has compatible peers: > 0.0.0.0/0 -> 0.0.0.0/0 [pri: 8] > pluto[13792]: | find_connection: first OK "server" [pri:8]{0x563e26c04ee8} > (child none) > pluto[13792]: | find_connection: concluding with "server" > [pri:8]{0x563e26c04ee8} kind=CK_TEMPLATE > pluto[13792]: cannot initiate connection for packet 10.0.0.13:57994 -> > 104.21.22.28:443 proto=6 - template conn > pluto[13792]: | initiate on demand using RSASIG from 10.0.0.13 to 104.21.22.28 > pluto[13792]: | kernel_process_msg_cb process netlink message > pluto[13792]: | netlink_get: XFRM_MSG_ACQUIRE message > pluto[13792]: | xfrm netlink msg len 376 > pluto[13792]: | xfrm acquire rtattribute type 5 > pluto[13792]: | xfrm acquire rtattribute type 16 > pluto[13792]: | add bare shunt 0x563e26bfefc8 10.0.0.13/32:41366 --6--> > 185.199.108.133/32:443 => %hold 0 %acquire-netlink > pluto[13792]: initiate on demand from 10.0.0.13:41366 to 185.199.108.133:443 > proto=6 because: acquire > pluto[13792]: | find_connection: looking for policy for connection: > 10.0.0.13:6/41366 -> 185.199.108.133:6/443 > pluto[13792]: | find_connection: conn "server" has compatible peers: > 0.0.0.0/0 -> 0.0.0.0/0 [pri: 8] > pluto[13792]: | find_connection: first OK "server" [pri:8]{0x563e26c04ee8} > (child none) > pluto[13792]: | find_connection: concluding with "server" > [pri:8]{0x563e26c04ee8} kind=CK_TEMPLATE > pluto[13792]: cannot initiate connection for packet 10.0.0.13:41366 -> > 185.199.108.133:443 proto=6 - template conn > pluto[13792]: | initiate on demand using RSASIG from 10.0.0.13 to > 185.199.108.133 > pluto[13792]: | timer_event_cb: processing event@0x563e26bef498 > pluto[13792]: | handling event EVENT_PENDING_DDNS > pluto[13792]: | event_schedule: new EVENT_PENDING_DDNS-pe@0x563e26c099f8 > pluto[13792]: | inserting event EVENT_PENDING_DDNS, timeout in 60.000 seconds > pluto[13792]: | elapsed time in connection_check_ddns for hostname lookup 0 > pluto[13792]: | free_event_entry: release EVENT_PENDING_DDNS-pe@0x563e26bef498 > pluto[13792]: | timer_event_cb: processing event@0x563e26c09988 > pluto[13792]: | handling event EVENT_SHUNT_SCAN > pluto[13792]: | expiring aged bare shunts from shunt table > pluto[13792]: | keeping recent bare shunt 0x563e26bfefc8 10.0.0.13/32:41366 > --6--> 185.199.108.133/32:443 => %hold 0 %acquire-netlink > pluto[13792]: | keeping recent bare shunt 0x563e26c05e18 10.0.0.13/32:57994 > --6--> 104.21.22.28/32:443 => %hold 0 %acquire-netlink > pluto[13792]: | keeping recent bare shunt 0x563e26c06018 10.0.0.13/32:40693 > --17--> 1.2.3.4/32:1025 => %hold 0 %acquire-netlink > pluto[13792]: | event_schedule: new EVENT_SHUNT_SCAN-pe@0x563e26c09a68 > pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds > pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe@0x563e26c09988 > > This leaves me with a lot of mysteries, e. g.: > - why is pluto trying rsasig when the config mandates psk? > - why is pluto connecting to 104.21.22.28 (dns.cloudflare.com) and > 185.199.108.133 (cdn-185-199-108-133.github.com) - and why through https? > - and what can I do to debug this and get it to work? > > Many thanks! > > Phil _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
