[Swan] Roadwarrior and NAT
Paul Wouters
paul at nohats.ca
Wed Oct 13 21:06:48 UTC 2021
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 <phil.nightowl at gmail.com> 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 at 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 at 0x563e26c09298
> pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds
> pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe at 0x563e26bef708
> pluto[13792]: | timer_event_cb: processing event at 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 at 0x563e26c09988
> pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds
> pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe at 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 at 0x563e26bef498
> pluto[13792]: | handling event EVENT_PENDING_DDNS
> pluto[13792]: | event_schedule: new EVENT_PENDING_DDNS-pe at 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 at 0x563e26bef498
> pluto[13792]: | timer_event_cb: processing event at 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 at 0x563e26c09a68
> pluto[13792]: | inserting event EVENT_SHUNT_SCAN, timeout in 20.000 seconds
> pluto[13792]: | free_event_entry: release EVENT_SHUNT_SCAN-pe at 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
More information about the Swan
mailing list