[strongSwan] Having forwarding issue in a basic StrongSwan setup
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Fri Jan 28 20:30:41 CET 2022
Hello Mohit,
That is an interesting root cause. Can you provide any more information about that and if it could be widespread?
Also, I presume you checked that through /proc/net/xfrm_stat, no?
Kind regards
Noel
Am 28.01.22 um 20:00 schrieb MOHIT CHALLA (mochalla):
> Hi Noel, Rajiv
>
> Many thanks for your prompt responses. Deeply appreciated!
>
> The issue turned out not to be a forwarding issue on linux, but incorrect ESP trailer encoding from the cloud service router due to which post-decryption check was failing on StrongSwan causing it to discard the packet.
>
> Thanks,
>
> Mohit
>
> *From: *Users <users-bounces at lists.strongswan.org> on behalf of Rajiv Kulkarni <rajivkulkarni69 at gmail.com>
> *Date: *Thursday, 27 January 2022 at 2:33 PM
> *To: *"users at lists.strongswan.org" <users at lists.strongswan.org>
> *Subject: *Re: [strongSwan] Having forwarding issue in a basic StrongSwan setup
>
> Hi
>
> On the Strongswan peer-gateway (ubuntu), try by adding the below before(preferably) or after the ipsec tunnel is up
>
> *root# ip route add 172.16.1.0/24 <http://172.16.1.0/24> dev ens224 table 220*
>
> I think it will then start the forwarding of the inbound (after decryption) packets correctly as expected.
>
> best regards
>
> On Thu, Jan 27, 2022 at 1:03 AM Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
>
> Hello Mohit,
>
> Please enable logging of martians. I suspect the return path filter and route installation into table 220 break it because the return path filter default mode of 1 just looks up the route in the main routing table, not routing table 220 into which strongSwan installs the routews. Assuming this is a fixed installation and the addresses of next hops and so on don't change you can disable the route installation by strongSwn and manage the required routes manually and put them into the main routing table.
> Mode 2 for the return path filter looks for routes in any routing table. Thus because the route installed in table 220 will likely match satisfy the return path filter, you'd have to change its mode to 2, or 0 (which disables it).
>
> You probably also want to use a VTI or an XFRM interface. For the first route installation needs to be disabled, and for the latter the return path filter won't cause any problems and strongSwan won't install any routes so you don't need to change that setting either.
>
> Kind regards
> Noel
>
> Am 26.01.22 um 14:30 schrieb MOHIT CHALLA (mochalla):
> > Hello group,
> >
> > I am trying to run some tests in my lab setup with a Cisco cloud service router on one side and running StrongSwan version 5.8.2 on the other side (Ubuntu 20.04LTS).
> >
> > I am using loopback interface on the Cisco side, and a normal interface on the Ubuntu side to simulate LAN networks and there is no NAT involved in-between.
> >
> > The connection has come up properly (verified on both sides). However, end-to-end ping connectivity from the LAN to LAN is not going through due to what appears to me to be a forwarding issue on the Ubuntu side.
> >
> > I suspect I am missing something basic here, but I am not able to figure it out. Any pointers are deeply appreciated.
> >
> > root at mochalla:~# swanctl -l
> >
> > csr: #2, ESTABLISHED, IKEv2, e3613778f4d39f6d_i ec5d278f976b8165_r*
> >
> > local '192.168.1.2' @ 192.168.1.2[500]
> >
> > remote '192.168.1.1' @ 192.168.1.1[500]
> >
> > AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
> >
> > established 581s ago, rekeying in 13147s
> >
> > csr: #3, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA1_96
> >
> > installed 15s ago, rekeying in 262s, expires in 315s
> >
> > in c33426a5, 0 bytes, 0 packets
> >
> > out a790e4e9, 0 bytes, 0 packets
> >
> > local 172.16.1.0/24 <http://172.16.1.0/24>
> >
> > remote 172.17.1.0/24 <http://172.17.1.0/24>
> >
> > root at mochalla:~# ip add
> >
> > <…>
> >
> > 3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> >
> > link/ether 00:50:56:bd:6d:f7 brd ff:ff:ff:ff:ff:ff
> >
> > altname enp11s0
> >
> > inet 192.168.1.2/24 <http://192.168.1.2/24> brd 192.168.1.255 scope global noprefixroute ens192
> >
> > valid_lft forever preferred_lft forever
> >
> > inet6 fe80::145d:7f77:fb57:e349/64 scope link noprefixroute
> >
> > valid_lft forever preferred_lft forever
> >
> > 4: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
> >
> > link/ether 00:50:56:bd:aa:76 brd ff:ff:ff:ff:ff:ff
> >
> > altname enp19s0
> >
> > inet 172.16.1.1/24 <http://172.16.1.1/24> brd 172.16.1.255 scope global noprefixroute ens224
> >
> > valid_lft forever preferred_lft forever
> >
> > inet6 fe80::f1b7:4eb:7e:fd89/64 scope link noprefixroute
> >
> > valid_lft forever preferred_lft forever
> >
> > On the Cisco side, I can see that the ping packets are getting encrypted
> >
> > Router#sh cry sess de | i pkts
> >
> > Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/3590
> >
> > Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4608000/3590
> >
> > Router#ping 172.16.1.1 so 172.17.1.1 re 10 ti 1
> >
> > Type escape sequence to abort.
> >
> > Sending 10, 100-byte ICMP Echos to 172.16.1.1, timeout is 1 seconds:
> >
> > Packet sent with a source address of 172.17.1.1
> >
> > ..........
> >
> > Success rate is 0 percent (0/10)
> >
> > Router#sh cry sess de | i pkts
> >
> > Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4608000/3526
> >
> > Outbound: #pkts enc'ed 10 drop 0 life (KB/Sec) 4607999/3526
> >
> > The ESP packets can be seen reaching the ens192 interface on Ubuntu in tcpdump.
> >
> > root at mochalla:~# tcpdump -i ens192
> >
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> >
> > listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
> >
> > 18:47:29.855345 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x1), length 148
> >
> > 18:47:30.854815 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x2), length 148
> >
> > 18:47:31.854795 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x3), length 148
> >
> > 18:47:32.855670 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x4), length 148
> >
> > 18:47:33.855818 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x5), length 148
> >
> > 18:47:34.856440 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x6), length 148
> >
> > 18:47:35.856364 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x7), length 148
> >
> > 18:47:36.855871 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x8), length 148
> >
> > 18:47:37.856339 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0x9), length 148
> >
> > 18:47:38.856668 IP 192.168.1.1 > mochalla: ESP(spi=0xce02423e,seq=0xa), length 148
> >
> > Looks like the route is also getting installed in table 220 as expected.
> >
> > root at mochalla:~# ip route show table 220
> >
> > 172.17.1.0/24 <http://172.17.1.0/24> via 192.168.1.1 dev ens192 proto static src 172.16.1.1
> >
> > If I try pinging from StrongSwan side to Cisco, I can see the reply ESP packets are reaching the ens192 interface, but not getting forwarded to ens224.
> >
> > root at mochalla:~# ping 172.17.1.1 -I ens224 -c10 -W1
> >
> > PING 172.17.1.1 (172.17.1.1) from 172.16.1.1 ens224: 56(84) bytes of data.
> >
> > root at mochalla:~# tcpdump -i ens192
> >
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> >
> > listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
> >
> > 18:54:31.317527 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0x9), length 132
> >
> > 18:54:31.317771 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x1d), length 132
> >
> > 18:54:32.325385 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xa), length 132
> >
> > 18:54:32.325675 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x1e), length 132
> >
> > 18:54:33.349423 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xb), length 132
> >
> > 18:54:33.349699 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x1f), length 132
> >
> > 18:54:34.373418 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xc), length 132
> >
> > 18:54:34.373637 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x20), length 132
> >
> > 18:54:35.397405 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xd), length 132
> >
> > 18:54:35.397704 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x21), length 132
> >
> > 18:54:36.421384 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xe), length 132
> >
> > 18:54:36.421756 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x22), length 132
> >
> > 18:54:37.445419 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0xf), length 132
> >
> > 18:54:37.445743 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x23), length 132
> >
> > 18:54:38.469436 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0x10), length 132
> >
> > 18:54:38.469731 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x24), length 132
> >
> > 18:54:39.493356 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0x11), length 132
> >
> > 18:54:39.493734 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x25), length 132
> >
> > 18:54:40.517449 IP mochalla > 192.168.1.1 <http://192.168.1.1>: ESP(spi=0x2816000e,seq=0x12), length 132
> >
> > 18:54:40.517762 IP 192.168.1.1 > mochalla: ESP(spi=0xc9a37c21,seq=0x26), length 132
> >
> > root at mochalla:~# sysctl -p
> >
> > net.ipv4.ip_forward = 1
> >
> > net.ipv6.conf.all.forwarding = 1
> >
> > root at mochalla:~# iptables-save
> >
> > # Generated by iptables-save v1.8.4 on Wed Jan 26 18:57:04 2022
> >
> > *filter
> >
> > :INPUT ACCEPT [1438:141334]
> >
> > :FORWARD ACCEPT [0:0]
> >
> > :OUTPUT ACCEPT [1780:162854]
> >
> > :ufw-after-forward - [0:0]
> >
> > :ufw-after-input - [0:0]
> >
> > :ufw-after-logging-forward - [0:0]
> >
> > :ufw-after-logging-input - [0:0]
> >
> > :ufw-after-logging-output - [0:0]
> >
> > :ufw-after-output - [0:0]
> >
> > :ufw-before-forward - [0:0]
> >
> > :ufw-before-input - [0:0]
> >
> > :ufw-before-logging-forward - [0:0]
> >
> > :ufw-before-logging-input - [0:0]
> >
> > :ufw-before-logging-output - [0:0]
> >
> > :ufw-before-output - [0:0]
> >
> > :ufw-logging-allow - [0:0]
> >
> > :ufw-logging-deny - [0:0]
> >
> > :ufw-not-local - [0:0]
> >
> > :ufw-reject-forward - [0:0]
> >
> > :ufw-reject-input - [0:0]
> >
> > :ufw-reject-output - [0:0]
> >
> > :ufw-skip-to-policy-forward - [0:0]
> >
> > :ufw-skip-to-policy-input - [0:0]
> >
> > :ufw-skip-to-policy-output - [0:0]
> >
> > :ufw-track-forward - [0:0]
> >
> > :ufw-track-input - [0:0]
> >
> > :ufw-track-output - [0:0]
> >
> > :ufw-user-forward - [0:0]
> >
> > :ufw-user-input - [0:0]
> >
> > :ufw-user-limit - [0:0]
> >
> > :ufw-user-limit-accept - [0:0]
> >
> > :ufw-user-logging-forward - [0:0]
> >
> > :ufw-user-logging-input - [0:0]
> >
> > :ufw-user-logging-output - [0:0]
> >
> > :ufw-user-output - [0:0]
> >
> > COMMIT
> >
> > I am not sure why the ping packets are not getting forwarded to the ens224 interface. Though the ipv4 forwarding option is set, I observe that the FORWARD chain counter is not increasing.
> >
> > Am I missing something basic here? Any pointers are deeply appreciated.
> >
> > Thanks,
> >
> > Mohit
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220128/d8e8ae36/attachment.sig>
More information about the Users
mailing list