[Swan] Use of nexthop setting
Scott A. Wozny
sawozny at hotmail.com
Tue Sep 22 23:47:56 UTC 2020
OK, I promise I won't reply "fixed it!" in a couple hours. 🙂 I've been beating my head against the wall all day on this so I've decided to admit defeat and consult the gurus here.
In my testing setup I have a pair of VPN systems, each with an VPNExternal interface (ens8), a VPNInternal (ens9) interface and a management interface (eth0) which is the default gateway for each machine. Each machine is connected to a test firewall and those firewalls are connected together with a pretend “Internet” segment.
I would like to have the isakmp and ipsec-nat-t traffic bound for the peer gateway travel out the interface identified as left on each machine, rather than out the default gateway as directed by the routing table. I thought this was the purpose of leftnexthop, but when I set it to the IP of the firewall’s address on the VPNExternal interface, traffic still goes to the default gateway whose interface on the firewall is NOT configured to pass this traffic and the tunnel does not come up.
Here are the configs and routing tables where each VPN system tries to send traffic out the default gateway which doesn’t work.
[sawozny at vpnnj ~]$ sudo cat /etc/ipsec.d/intersitetunnel.conf
# /etc/ipsec.d/intersitetunnel.conf
conn intersitetunnel
left=10.1.2.2
leftnexthop=10.1.2.1
leftid=@vpnnj
leftsubnet=10.1.4.0/24
leftrsasigkey=0sAwEAAcQQa4wVLATC...
right=172.16.1.10
rightid=@vpnca
rightsubnet=10.1.7.0/24
rightrsasigkey=0sAwEAAcp4iq2wyRGr212...
authby=rsasig
auto=start
[sawozny at vpnnj ~]$ ip route
default via 192.168.1.1 dev eth0 proto static metric 100
10.1.2.0/24 dev ens8 proto kernel scope link src 10.1.2.2 metric 101
10.1.3.0/24 dev ens9 proto kernel scope link src 10.1.3.2 metric 102
10.1.4.0/24 via 10.1.3.1 dev ens9 proto static metric 102
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.214 metric 100
[sawozny at vpnnj ~]$ sudo systemctl start ipsec
[sawozny at vpnnj ~]$ sudo ip xfrm state
[sawozny at vpnnj ~]$
[sawozny at vpnca ~]$ sudo cat /etc/ipsec.d/intersitetunnel.conf
# /etc/ipsec.d/intersitetunnel.conf
conn intersitetunnel
left=10.1.5.2
leftnexthop=10.1.5.1
leftid=@vpnca
leftsubnet=10.1.7.0/24
leftrsasigkey=0sAwEAAcp4iq2wyRGr212...
right=172.16.1.2
rightid=@vpnnj
rightsubnet=10.1.4.0/24
rightrsasigkey=0sAwEAAcQQa4wVLATC...
authby=rsasig
auto=start
[sawozny at vpnca ~]$ ip route
default via 192.168.1.1 dev eth0 proto static metric 100
10.1.5.0/24 dev ens8 proto kernel scope link src 10.1.5.2 metric 101
10.1.6.0/24 dev ens9 proto kernel scope link src 10.1.6.2 metric 102
10.1.7.0/24 via 10.1.6.1 dev ens9 proto static metric 102
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.215 metric 100
[sawozny at vpnca ~]$ sudo systemctl start ipsec
[sawozny at vpnca ~]$ sudo ip xfrm state
[sawozny at vpnca ~]$
🙁
But when I add an explicit route to the peer VPN server on each side, the tunnel comes up and passes traffic.
[sawozny at vpnnj ~]$ sudo nmcli con mod tobr20 +ipv4.routes "172.16.1.10/32 10.1.2.1"
[sawozny at vpnnj ~]$ sudo systemctl restart network
[sawozny at vpnnj ~]$ sudo ip xfrm state
src 172.16.1.10 dst 10.1.2.2
proto esp spi 0xc7c336b4 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x5c2563f818e5e411e08e2d78f5327afc80d1eb16 96
enc cbc(aes) 0x22888c791947836f61d0f899d0c835d1
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.2.2 dst 172.16.1.10
proto esp spi 0x7729d983 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x783f6a9ee168efddc3e38cbb4440a9e6c4497277 96
enc cbc(aes) 0x114e1305eefabd753d02f8140a08d328
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 172.16.1.10 dst 10.1.2.2
proto esp spi 0xb07520a7 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x9cd14cc3fd16c4780f8fb714fd083fbccbb26630 96
enc cbc(aes) 0x801047bbe092a3bca30f7d938fd94a3b
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.2.2 dst 172.16.1.10
proto esp spi 0xc259c0ec reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x43eb34e0c29e9c8e4bf0b4be47e1deff2e7c32a0 96
enc cbc(aes) 0x2c0d85159e213dee7876cd8508a945e7
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 172.16.1.10 dst 10.1.2.2
proto esp spi 0x468f70f9 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x8daf260644eb32cf958b4fc67e6674123a4d2175 96
enc cbc(aes) 0x5908770ce43fe778944115953787fe64
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.2.2 dst 172.16.1.10
proto esp spi 0x1ff6106f reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xd6eef64a653b77b6c5c68724dcbdb2a81d3efd6a 96
enc cbc(aes) 0x833e3d2c824519571d7df8ed948f501c
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
[sawozny at vpnnj ~]$ ip route
default via 192.168.1.1 dev eth0 proto static metric 100
10.1.2.0/24 dev ens8 proto kernel scope link src 10.1.2.2 metric 101
10.1.3.0/24 dev ens9 proto kernel scope link src 10.1.3.2 metric 102
10.1.4.0/24 via 10.1.3.1 dev ens9 proto static metric 102
172.16.1.10 via 10.1.2.1 dev ens8 proto static metric 101
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.214 metric 100
[sawozny at vpnnj ~]$
[sawozny at vpnca ~]$ sudo nmcli con mod tobr50 +ipv4.routes "172.16.1.2/32 10.1.5.1"
[sawozny at vpnca ~]$ sudo systemctl restart network
[sawozny at vpnca ~]$ sudo ip xfrm state
src 172.16.1.2 dst 10.1.5.2
proto esp spi 0x7729d983 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x783f... 96
enc cbc(aes) 0x114e...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.5.2 dst 172.16.1.2
proto esp spi 0xc7c336b4 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x5c25... 96
enc cbc(aes) 0x2288...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 172.16.1.2 dst 10.1.5.2
proto esp spi 0xc259c0ec reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x43eb... 96
enc cbc(aes) 0x2c0d...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.5.2 dst 172.16.1.2
proto esp spi 0xb07520a7 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x9cd1... 96
enc cbc(aes) 0x8010...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 172.16.1.2 dst 10.1.5.2
proto esp spi 0x1ff6106f reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0xd6ee... 96
enc cbc(aes) 0x833e...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.1.5.2 dst 172.16.1.2
proto esp spi 0x468f70f9 reqid 16389 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha1) 0x8daf... 96
enc cbc(aes) 0x5908...
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
[sawozny at vpnca ~]$ ip route
default via 192.168.1.1 dev eth0 proto static metric 100
10.1.5.0/24 dev ens8 proto kernel scope link src 10.1.5.2 metric 101
10.1.6.0/24 dev ens9 proto kernel scope link src 10.1.6.2 metric 102
10.1.7.0/24 via 10.1.6.1 dev ens9 proto static metric 102
172.16.1.2 via 10.1.5.1 dev ens8 proto static metric 101
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.215 metric 100
[sawozny at vpnca ~]$
This was how I had things working before I started messing around with nexthop. I can live with this as a workaround, but can anyone tell me what I did wrong with the use of nexthop?
Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20200922/129392dd/attachment-0001.html>
More information about the Swan
mailing list