0

I've got a VPN tunnel (ipsec / StrongSwan) setup, connected. The other side is apparently able to ping me through the tunnel. However a ping from my side is said to be never received on the other side. The other side (that I cannot control) is thus assuming it's a configuration issue from my side.

I'm really not sure about this, because I can see the ping packets going out when tcpdumping:

$ ping -c 5 192.168.33.1
PING 192.168.33.1 (192.168.33.1) 56(84) bytes of data.
--- 192.168.33.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4009ms

(at the same time in another console)
$ tcpdump host REMOTE
09:22:07.539582 IP OURS > REMOTE: ESP(spi=0xXXXXXX,seq=0x3), length 132
09:22:08.547608 IP OURS > REMOTE: ESP(spi=0xXXXXXX,seq=0x4), length 132
(... one packet per ping ...)

The ESP traffic is obviously my ping. To make sure I've disabled all firewalling from my side.

Thus my question: How can I make sure the ping packets are going out and received? What can be the cause and what can I do more to help debug the issue?

As a side note, I've got another VPN setup and working, using the exact same configuration.

Some infos on the tunnel:

$ ipsec statusall chtunnel
Security Associations (2 up, 0 connecting):
   chtunnel[377]: ESTABLISHED 5 minutes ago, OURS[OURS]...REMOTE[REMOTE]
   chtunnel[377]: IKEv1 SPIs: xxxxxxx_i* xxxxxxxxxx_r, pre-shared key reauthentication in 39 minutes
   chtunnel[377]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
   chtunnel{442}:  INSTALLED, TUNNEL, reqid 45, ESP SPIs: xxxxxx_i xxxxxx_o
   chtunnel{442}:  AES_CBC_256/HMAC_SHA1_96/MODP_1024, 0 bytes_i, 756 bytes_o (9 pkts, 22s ago), rekeying in 26 minutes
   chtunnel{442}:   192.168.32.1/32 === 192.168.33.0/24

The stats 756 bytes_o (9 pkts, 22s ago) do indeed increase (one packet per ping) when I send the pings.

Laurent Grégoire
  • 121
  • 7
  • How does the status output of strongSwan look like (e.g. `ipsec statusall` or `swanctl -l`)? Do the traffic counters increase with each ping? Any NAT firewall rules that might interfere? – ecdsa Jun 17 '19 at 08:40
  • Added output of `ipsec status`. There is no NAT firewall on our side, the server is directly connected to the internet with a static public IP. As for the traffic counter, it's hard to say as the server do have lots of traffic. – Laurent Grégoire Jun 17 '19 at 09:42
  • You get counters per SA if you use @ipsec statusall@. Also note that you have two CHILD_SAs there (one rekeyed), maybe the peer somehow is confused as to which SA should be used (does it work in the beginning and stops later? or doesn't it work even when only one CHILD_SA exists?). – ecdsa Jun 17 '19 at 11:09
  • What does `ip route get 192.168.33.1` show, particularly the source IP is interesting. – wurtel Jun 17 '19 at 12:01
  • @wurtel `ip route get 192.168.33.1` shows `192.168.33.1 via X.Y.Z.254 dev eth0 src 192.168.32.1 / cache` with X.Y.Z.208 being the public IP of my server – Laurent Grégoire Jun 17 '19 at 16:33
  • @ecdsa How do you see that there is two CHILD_SAs? – Laurent Grégoire Jun 17 '19 at 16:50
  • That's what the output of `ipsec status` showed. In the output of `statusall` only one CHILD_SA can be seen. Looks like the issue is on the other end, as packets apparently leave your host correctly. – ecdsa Jun 18 '19 at 08:19

1 Answers1

1

capturing the traffic with tcpdump specifically for the tunnel interface should show you if the traffic is leaving over the tunnel, this way you can be sure that the traffic is being received on the other end of the VPN.

This will show you the traffic encrypted. If you want to check specifically all the traffic you can follow this wiki from strongswan wiki:

https://wiki.strongswan.org/projects/strongswan/wiki/CorrectTrafficDump

most likely the other end is not accepting the traffic by dropping it in some firewall, but this way you can be sure and can ask them to check on their side

Alejandro Vázquez
  • 94
  • 4