7

Not sure if this is a good stack exchange site to post this on but here goes nothing,

The problem, As you can see from my Wireshark screenshot the TCP handshake is not happening. The remote is sending me the SYN message but I'm not responding to SYN/ACK. I can connect just fine with my own socket client and watch the handshake work perfectly, the only difference being I'm not accessing our server through the VPN tunnel.

The backstory, is we've been tasked with connecting to a remote service (192.168.X.X) that is essentially a black box to us. Both systems are connected via an IPSec tunnel. Communication is supposed to be done through a TCP socket with our end (172.31.0.5) implemented in python acting as the server. All we know about their end is that it's running on Windows. Their end is configured with an IP and port, that's it.

Thank you for your time.

Wirehsark capture (pcapng) Wireshark output tcpdump raw capture

Kindle Q
  • 149
  • 8
anders
  • 195
  • 6
  • I assume you can ping the remote host. I can't tell for sure but I see you send a SYN, then you send an ACK. Is it possible the remote host is sending a SYN-ACK, but you're not capturing it? – Ron Trunk Aug 19 '15 at 14:11
  • Yes I can ping the remote host. I'm not sure by your comment but just to be clear my side of the connection, being the `server`, is the 172.31.0.5. So I'm the one not responding to the remote hosts SYN messages for some reason. – anders Aug 19 '15 at 14:25
  • OK, but I see the remote side sending you an ACK. That would normally happen if you sent a SYN-ACK to the remote. If you never sent anything, the remote would just send another SYN. So is it possible you're not capturing all the packets? – Ron Trunk Aug 19 '15 at 14:30
  • Thats a good point Ron. Unfortunately I don't think thats the case because 1) the remote is suppose to initiate communication with us periodically and 2) I'm capturing all data on that interface with no filters. I just added the wireshark capture data to my question – anders Aug 19 '15 at 14:32
  • If you don't send a SYN-ACK, there would be no "handshake" and the remote would never send an ACK. That fact that it does suggests something else is going on. What would the remote be acknowledging? – Ron Trunk Aug 19 '15 at 14:35
  • I have no idea, I'm thoroughly confused. When I try and make a connection from my own client I see the SYN/ACK messages. I'm wondering if the VPN has something to do with this. I'm running strongswan on the same machine as my socket server, which also happens to be the machine I'm capturing the captures from. – anders Aug 19 '15 at 14:40
  • 1
    Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/27142/discussion-between-anders-and-ron-trunk). – anders Aug 19 '15 at 14:46

1 Answers1

10

We were able to come to the answer in the chat room. It appears this is a symptom of StrongSwan itself. From their FAQ:

Capturing outbound plaintext packets with tcpdump/wireshark
Q: When using tcpdump/wireshark to sniff traffic secured by IPsec, incoming packets show up twice: encrypted i.e. as ESP packets and unencrypted as plaintext packets. However, for outgoing traffic, only ESP packets show up. How can I get incoming and outgoing packets as plaintext?

A: That's a peculiarity of the Linux kernel. Capture the (UDP encapsulated) ESP packets and use wireshark to decrypt them. See http://wiki.wireshark.org/ESP_Preferences Run the following command to determine the encryption algorithms and the symmetric keys used by the kernel. Depending on your configuration, strongSwan periodically changes encryption keys. Keep this in mind if you are capturing traffic over an extended period of time.

ip xfrm state

Its also documented in one of their issues:
https://wiki.strongswan.org/issues/470

Eddie
  • 14,808
  • 6
  • 42
  • 82