[strongSwan] Having forwarding issue in a basic StrongSwan setup

Rajiv Kulkarni rajivkulkarni69 at gmail.com
Thu Jan 27 10:03:04 CET 2022


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
> >
> > remote 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 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 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 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: 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: 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: 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: 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: 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: 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: 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:
> 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:
> 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:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220127/a51e9458/attachment-0001.html>


More information about the Users mailing list