[strongSwan] VTI route-based configuration problem
Volodymyr Litovka
doka.ua at gmx.com
Sun Feb 21 10:35:29 CET 2021
Hi Ben,
take a look into
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
it seems you have a mesh in the configuration - your stronSwan's
configuration is completely policy-based, while you think you use VTIs
and routing.
On 18.02.2021 03:00, Ben Tullis wrote:
> 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
>
--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210221/f8546496/attachment-0001.html>
More information about the Users
mailing list