[strongSwan] VTI route-based configuration problem

Ben Tullis ben.tullis at opencorporates.com
Thu Feb 18 02:00:24 CET 2021


Hello,

I wonder if anyone might be able to help me work out what I'm doing 
wrong please. I've been struggling with it for days on end.

Primarily I'm trying to follow this tutorial: 
https://cloud.google.com/community/tutorials/using-cloud-vpn-with-strongswan

...to set up a tunnel mode IPSec connection between on-premise 
strongSwan on Debian 9 and Google Cloud Project VPN gateway, using bird 
for routing.

The topology is broadly as follows:


         +----------------------------------------------+
         |                                              |
    eth0 | 94.190.242.6                                 | 35.242.22.169
  +------+-------------+                           +------+--------------+
  |  vti0:169.254.1.2  |                           | router: 169.254.1.1 |
  |                    |                           |                     |
  |                    |                           |                     |
  |  strongSwan 5.5    |                           | Google Cloud HA VPN |
  |  on Debian 9       |                           |                     |
  |                    |                           |                     |
  +------+-------------+                           +------+--------------+
   bond0 | 10.43.0.1                                     |
         |                                               |
         |                                               |
         +                                               +
    10.43.0.0/16                                     10.44.0.0/16

The server on the left is the default gateway for the 10.43.0.0/16 
network behind it. Only traffic for 10.44.0.0/16 should go over the tunnel.

In the tutorial a /30 subnet is used for the BGP traffic and I have used 
169.254.1.1 for the cloud router, with 169.254.1.2 for the Linux vti0 
interface.

My SA appears to be created correctly. 'ipsec statusall' output is 
pasted below.

The xfrm policy looks to be OK to me too. 'ip xfrm policy' output is 
pasted below.

When I use tcpdump on the vti0 interface I can see BGP traffic, but when 
I look at 'ip -s tunnel show' I can see that all TX packets are 
generating errors with a 'NoRoute' status. Like this...

> root at gw1:~# ip -s tunnel show
> ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0
> RX: Packets    Bytes        Errors CsumErrs OutOfSeq Mcasts
>     0          0            0      0        0        0       
> TX: Packets    Bytes        Errors DeadLoop NoRoute  NoBufs
>     0          0            0      0        0        0     
> vti0: ip/ip remote 35.242.22.169 local 94.190.242.6 ttl inherit nopmtudisc key 1
> RX: Packets    Bytes        Errors CsumErrs OutOfSeq Mcasts
>     2761       165660       0      0        0        0       
> TX: Packets    Bytes        Errors DeadLoop NoRoute  NoBufs
>     0          0            2880   0        2880     0   

I've tried making sure that I'm only using a single routing table.

I've tried disabling the firewall and setting all iptables policies to 
ACCEPT.

I've tried setting left|rightsubnet to 0.0.0.0/0 instead of the 
10.43.0.0/16 and 10.44.0.0/16 values.

The following are all set by the leftupdownscript:

> net.ipv4.conf.eth0.disable_xfrm = 1
> net.ipv4.conf.eth0.disable_policy = 1
> net.ipv4.conf.vti0.disable_xfrm = 1
> net.ipv4.conf.vti0.disable_policy = 1
> net.ipv4.ip_forward = 1

I've tried changing the script so that it disabled the policy and xfrm 
on bond0 (the lan interface) rather than eth0 (the wan interface) but it 
hasn't made any difference to this issue. I still see the NoRoute 
errors. it chooses eth0 because it is the $PLUTO_INTERFACE variable, but 
I wasn't certain which it should be.

If anyone has any insight into how I can make this work, I'd be very 
grateful. I've poseted as much debug info below as I can think of.

Kind regards,
Ben

The ipsec connection file is as follows:

> cat /etc/ipsec.d/gcp.conf 
> conn %default
>     ikelifetime=600m # 36,000 s
>     keylife=180m # 10,800 s
>     rekeymargin=3m
>     keyingtries=3
>     keyexchange=ikev2
>     mobike=no
>     #ike=aes256gcm16-sha512-modp4096 # wouldn't connect with this
>     esp=aes256gcm16-sha512-modp8192
>     authby=psk
> 
> conn gcp-prod
>     leftupdown="/var/lib/strongswan/ipsec-vti.sh 0 169.254.1.1/30 169.254.1.2/30"
>     left=94.190.242.6
>     leftid=94.190.242.6
>     leftsubnet=10.43.0.0/16
>     leftauth=psk
>     right=35.242.22.169
>     rightid=35.242.22.169
>     rightsubnet=10.44.0.0/16
>     rightauth=psk
>     type=tunnel
>     auto=add
>     dpdaction=restart
>     mark=%unique

'ipsec statusall' shows this:

> Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-14-amd64, x86_64):
>   uptime: 24 minutes, since Feb 17 23:36:00 2021
>   malloc: sbrk 2433024, mmap 0, used 288320, free 2144704
>   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
>   loaded plugins: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc hmac attr kernel-netlink resolve socket-default stroke updown
> Listening IP addresses:
>   94.190.242.6
>   94.190.242.132
>   192.168.10.100
>   10.43.0.10
>   169.254.1.2
> Connections:
>     gcp-prod:  94.190.242.6...35.242.22.169  IKEv2, dpddelay=30s
>     gcp-prod:   local:  [94.190.242.6] uses pre-shared key authentication
>     gcp-prod:   remote: [35.242.22.169] uses pre-shared key authentication
>     gcp-prod:   child:  10.43.0.0/16 === 10.44.0.0/16 TUNNEL, dpdaction=restart
> Security Associations (1 up, 0 connecting):
>     gcp-prod[2]: ESTABLISHED 24 minutes ago, 94.190.242.6[94.190.242.6]...35.242.22.169[35.242.22.169]
>     gcp-prod[2]: IKEv2 SPIs: bd548d31aa21287f_i 1a8c6dee54f1888b_r*, pre-shared key reauthentication in 9 hours
>     gcp-prod[2]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
>     gcp-prod{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cebf075b_i a0809ae4_o
>     gcp-prod{1}:  AES_GCM_16_256, 130800 bytes_i, 0 bytes_o, rekeying in 2 hours
>     gcp-prod{1}:   10.43.0.0/16 === 10.44.0.0/16

'ip route ls' shows this:
> default via 94.190.242.1 dev eth0 onlink 
> 10.43.0.0/16 dev bond0 proto kernel scope link src 10.43.0.10 
> 10.44.0.0/16 dev vti0 scope link 
> 94.190.242.0/25 dev eth0 proto kernel scope link src 94.190.242.6 
> 94.190.242.128/25 dev eth0 proto kernel scope link src 94.190.242.132 
> 169.254.1.0/30 dev vti0 proto kernel scope link src 169.254.1.2 
> 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.100

'ip route ls' shows this:
> default via 94.190.242.1 dev eth0 onlink 
> 10.43.0.0/16 dev bond0 proto kernel scope link src 10.43.0.10 
> 94.190.242.0/25 dev eth0 proto kernel scope link src 94.190.242.6 
> 94.190.242.128/25 dev eth0 proto kernel scope link src 94.190.242.132 
> 169.254.1.0/30 dev vti0 proto kernel scope link src 169.254.1.2 
> 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.100 

'birdc show route' shows this:
> BIRD 1.6.3 ready.
> 0.0.0.0/0          via 94.190.242.1 on eth0 [kernel1 00:50:45] * (10)
> 169.254.1.0/30     dev vti0 [direct1 00:50:45] * (240)
> 94.190.242.128/25  dev eth0 [direct1 00:50:45] * (240)
> 94.190.242.0/25    dev eth0 [direct1 00:50:45] * (240)
> 192.168.10.0/24    dev eth1 [direct1 00:50:45] * (240)
> 10.43.0.0/16       dev bond0 [direct1 00:50:45] * (240)

'ip rule ls' shows this:
> 0:	from all lookup local 
> 220:	from all lookup 220 
> 32766:	from all lookup main 
> 32767:	from all lookup default 

'ip a sh vti0' shows this:
> 11: vti0 at NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1387 qdisc noqueue state UNKNOWN group default qlen 1
>     link/ipip 94.190.242.6 peer 35.242.22.169
>     inet 169.254.1.2 peer 169.254.1.1/30 scope global vti0
>        valid_lft forever preferred_lft forever

'ip a sh ip_vti0' shows this:
> 9: ip_vti0 at NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
>     link/ipip 0.0.0.0 brd 0.0.0.0



More information about the Users mailing list