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 <[email protected]> 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@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@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@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@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@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@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@mochalla:~# sysctl -p > > > > net.ipv4.ip_forward = 1 > > > > net.ipv6.conf.all.forwarding = 1 > > > > root@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 > > >
