Strongswan VPN ping issue

[SB8767]

I'm facing an issue with a client that I set up a StrongSwan VPN with. The client cannot ping my server when the tunnel is up. Also, the client has pings disabled on their subnet.

My server has 2 VPNs running (one setup with IKEv1 which works fine and the other VPN which I'm currently facing an issue).

See below ifconfig setup:

eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.108.40 netmask 255.255.255.248 broadcast 192.168.108.47
ether 16:a7:4d:68:fa:2f txqueuelen 1000 (Ethernet)

VPN tunnel is up:
sudo ipsec status
Security Associations (2 up, 0 connecting):
vpn-deleted[52]: ESTABLISHED 77 seconds ago

$ sudo ip route show
192.168.108.40/29 dev eth0 proto kernel scope link src 192.168.108.40

iptables -L output:
ACCEPT all -- 10.240.209.128/29 admin-2/29 policy match dir in pol ipsec reqid 8 proto esp
ACCEPT all -- admin-2/29 10.240.209.128/29 policy match dir out pol ipsec reqid 8 proto esp
ACCEPT icmp -- anywhere anywhere icmp echo-request
The CX is pinging from 10.240.209.129 to 192.168.108.41 and getting no response.

tcpdump -i eth0 shows me my home IP ssh'ing on to the server.

conn vpn-test
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=serverpublicp
leftsubnet=192.168.108.40/29
leftid=10.131.112.99
leftfirewall=yes
right=clientpublicip
rightsubnet=10.240.209.128/29
rightfirewall=yes
ike=aes256-sha512-modp2048,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha-modp2048!
esp=aes256-sha512-modp2048,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048!
dpdaction=restart
ikelifetime=86400s
lifetime=3600s
dpddelay=20s
dpdtimeout=60s

What has been missed in the config/setup to cause the remote host not to be able to ping my eth0:1 subnet?

[tobiasbrunner]

The client cannot ping my server when the tunnel is up.

What kind of client?

Also, the client has pings disabled on their subnet.

What does that mean?

VPN tunnel is up:
sudo ipsec status
Security Associations (2 up, 0 connecting):
vpn-deleted[52]: ESTABLISHED 77 seconds ago

Please post the complete output (preferably of ipsec statusall) because this does not show whether there is a CHILD_SA established.

$ sudo ip route show

strongSwan usually installs routes in table 220 for established CHILD_SAs. If not, check the log.

What has been missed in the config/setup to cause the remote host not to be able to ping my eth0:1 subnet?

eth0:1 is a legacy thing (as is ifconfig). This is just an additional address on eth0 with that label (check ip addr). Note that 192.168.108.40 is technically the network ID of that /29 subnet, the first assignable address is 192.168.108.41.

[SB8767]

Thank you. I downloaded iftop and I can't see any traffic coming from the customer public IP.

I have been looking into prerouting and postrouting and I also come across this:
Link: https://docs.strongswan.org/docs/5.9/howtos/forwarding.html

If the VPN gateway is not the default gateway of the LAN, ICMP redirects might get returned to hosts if they send traffic destined for the remote hosts/subnets to the VPN gateway, directing them to the default gateway of the LAN (which probably doesn’t work and otherwise might get that traffic out unencrypted). To avoid this, disable sending such ICMP messages by setting

net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

Have I read that wrong or does that mean all ICMP traffic is sent back to the host if the VPN gateway is not the default gateway and that could explain why the client cannot ping our eth0:1 IP

[tobiasbrunner]

That's only an issue if the pinged host is behind the gateway, i.e. not if an IP of the gateway itself is pinged. As I said before, if you don't see any incoming traffic, the problem is either at the other end or due to a firewall between the two hosts (could be on your end if your firewall rules are restrictive).

[SB8767]

Thank you.

I have IPTables that allow my private subnet eth0:1 to the customer private subnet and vice versa.

The VPN is up and I can't see any packets passing. I have a call booked with the customer this Thursday. Can I leave this ticket open until then in case they ask me to make further changes

[SB8767]

I just had a call with the customer and I need your advice/ help please.

Customer requested we use the subnet 192.168.108.40/29, so we created a virtual interface of 192.168.108.41 (this was changed following your advice) and the interface was named eth0:1

The LEFTID of the ipsec.conf is my server LAN IP.

The customer said the VPN is going through the tunnel and hitting eth1(LAN IP) first then is forward to 192.168.108.41.

The CX went on to say there should be a DNAT rule to eh0:1, so when traffic goes through the tunnel and hits my side of the VPN, it will hit eth1 then be forwarded to eth0:1, which there is, however, I can't see any traffic the eth1 interface from their source address.

The weird thing is, this ubuntu server already have a VPN up and running without any issues. The customer can ping a different virtual interface and receive replies.

[tobiasbrunner]

Customer requested we use the subnet 192.168.108.40/29, so we created a virtual interface of 192.168.108.41 (this was changed following your advice) and the interface was named eth0:1

Again, that's not an interface, you just added an additional IP address to eth0 (you could also add it to eth1 or lo, or add it directly without the eth0:1 label, has the same effect).

The customer said the VPN is going through the tunnel and hitting eth1(LAN IP) first then is forward to 192.168.108.41.

Not sure what they mean or why that would be relevant.

The CX went on to say there should be a DNAT rule to eh0:1

No, that's not necessary. If the destination address of the tunneled packet is 192.168.108.41, it's a local address, no matter on what interface it is. There is no need to use DNAT to change the destination address unless they send packets that have a different destination address. However, then this wouldn't work at all as only packets with a destination address in 192.168.108.40/29 even get tunneled (that's the point of IPsec policies).

however, I can't see any traffic the eth1 interface from their source address.

Which, again, probably means that the problem is on their end (i.e. no packets are sent at all, maybe because they are not matching the negotiated traffic selectors) or between the two hosts (sent packets are dropped by a firewall for some reason). Since you already have a running VPN but you don't see any ESP packets for this new one, it's unlikely the issue is on your end at this point. Unless the existing VPN uses UDP encapsulation (UDP port 4500) but this one doesn't and your firewall drops plain ESP packets (IP protocol 50). So make sure to check your firewall rules.