[strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

[Tiago Stoco]

Hi Tobias,

First of all, THANKS for replying and clarifying some settings.

I have completely disabled the bypass-lan plugin since I do not have a use for it right now.

[root at arch-linux ~]# cat /etc/strongswan.conf
...
       plugins {
               include strongswan.d/charon/*.conf
               bypass-lan {
                       load = no
               }
...

And, I have moved the route for the VTI to table 220 because it seems to be the right way to config routed based IPSec VPN.

[root at arch-linux ~]# ip rule
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

[root at arch-linux ~]# ip r s t 220
10.10.10.0/30 via 10.10.10.2 dev ip_vti1 src 10.10.10.2

[root at arch-linux ~]# ip route
default via 192.168.45.1 dev ens18
192.168.45.0/24 dev ens18 proto kernel scope link src 192.168.45.30

I am going to add some more details of my configs because the TX Errors NoRoute are still present.

7: ip_vti1 at NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN group default qlen 1000
   link/ipip 192.168.45.30 peer 192.168.45.10 promiscuity 0 minmtu 0 maxmtu 0
   vti remote 192.168.45.10 local 192.168.45.30 ikey 0.0.0.42 okey 0.0.0.42 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
   inet 10.10.10.2 peer 10.10.10.1/32 scope global ip_vti1
      valid_lft forever preferred_lft forever
   inet6 fe80::5efe:c0a8:2d1e/64 scope link
      valid_lft forever preferred_lft forever

I can also see that the IPSec added some rules to MARK packets in my iptables.

-A PREROUTING -d 10.10.10.0/30 -c 2352 230776 -j MARK --set-xmark 0x2a/0xffffffff
-A OUTPUT -d 10.10.10.0/30 -c 3605 336028 -j MARK --set-xmark 0x2a/0xffffffff

The counters confirms that the packets are being marked. I am not sure if I should keep the MARK in iptables or remove it allowing routing decisions to send the packets to the VTI device that will MARK the packets but according to my understanding it should not matter.

[root at arch-linux ~]# ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0
       socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
       socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
       socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
       socket out priority 0 ptype main
src ::/0 dst ::/0
       socket in priority 0 ptype main
src ::/0 dst ::/0
       socket out priority 0 ptype main
src ::/0 dst ::/0
       socket in priority 0 ptype main
src ::/0 dst ::/0
       socket out priority 0 ptype main

Above are the policies installed. Again, because it is a routed base VPN seems correct.

[root at arch-linux ~]# ip xfrm state
src 192.168.45.30 dst 192.168.45.10
       proto esp spi 0xc2239b57 reqid 1 mode tunnel
       replay-window 0 flag af-unspec
       mark 0x2a/0xffffffff
       aead rfc4106(gcm(aes)) 0x264acee3119a4e523af2fbf5905b50c5acc1f7be9079ff23ffa2c6473a9c507fe1ae936b 128
       anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 192.168.45.10 dst 192.168.45.30
       proto esp spi 0xc661b9e5 reqid 1 mode tunnel
       replay-window 32 flag af-unspec
       aead rfc4106(gcm(aes)) 0x69a86fa6ca9448bece6ffdff77893f0e9ce5ebef604040f681b5cdd2d5976438ed005df1 128
       anti-replay context: seq 0x656, oseq 0x0, bitmap 0xffffffff

I have added a few more NFLOG captures into my iptables and I am a bit confused with the results.

A tcpdump capture in the VTI interface with a ping from the remote ( pfSense - 10.10.10.1 ) shows :

No   Time      Source        Destination

1 0.000000 10.10.10.1 10.10.10.2 ICMP 84 Echo (ping) request  id=0x9877, seq=471/55041, ttl=64 (reply in 2)
2 0.000038 10.10.10.2 > 10.10.10.1 ICMP 84 Echo (ping) reply    id=0x9877, seq=471/55041, ttl=64 (request in 1)

I do not see the IPSec MARK in these packets.
The reply packets end up in the OUTPUT chain marked but not encrypted as an ESP packet. By the way I do not see the replies even being encapsulated at all by IPSec.

Also, the NAT chain is not having packets passing through it.

[root at arch-linux ~]# snat
-P PREROUTING ACCEPT -c 0 0
-P INPUT ACCEPT -c 0 0
-P OUTPUT ACCEPT -c 0 0
-P POSTROUTING ACCEPT -c 0 0
-A PREROUTING -c 0 0 -j NFLOG --nflog-group 9

That is odd cause I am not able to manipulate the packets.

I will run a ping from the local Linux (10.10.10.2) and see how the packets are flowing through the iptables chains and will update in another email.

In the meantime, if someone sees something that I am missing. Please let me know.

Many Thanks.
________________________________
From: Tobias Brunner <tobias at strongswan.org>
Sent: Tuesday, August 31, 2021 5:51 AM
To: Tiago Stoco <tmsblink at msn.com>; users at lists.strongswan.org <users at lists.strongswan.org>
Subject: Re: [strongSwan] IPSec route based VPN - VTI interface TX Errors NoRoute

Hi Tiago,

> Pings from the Linux system are being seem as errors NoRoute by the tunnel. > ...
> Shunted Connections:
> Bypass LAN 10.10.10.0/30:  10.10.10.0/30 === 10.10.10.0/30 PASS

The reason is most likely this passthrough IPsec policy installed by the
bypass-lan plugin for the subnet that is reachable (according to the
main routing table) via ip_vti1.  For a ping from 10.10.10.2 to
10.10.10.1, the VTI interface won't find an IPsec policy to protect the
packet (the passthrough policy has a higher priority), so it gets dropped.

To avoid that, either install the routes via VTI in table 220 (which is
ignored by the bypass-lan plugin automatically), exclude the VTI
interface explicitly via charon.plugins.bypass-lan.interfaces_ignore, or
just disable the bypass-lan plugin completely if you don't need it.

Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210831/afeeb1b1/attachment-0001.html>