Site to site IPsec suspect not passing TCP traffic

graciejane

SSH remote to local works too. Here's what works and what doesn't:

Local --> remote:
Ping: yes
SSH: no
HTTP: no
RDP: yes

Remote --> local:
Ping: yes
SSH: yes
HTTP: yes
RDP: yes

scurrier

I am having issues with my setup as well and they lead to intermittent connectivity. Sometimes things work, sometimes not. Mostly not. They kind of sound like what you're experiencing.

One thing to consider is that packet size and fragmentation issues can lead to what you're seeing. You might be loading a big web page in one direction which leads to large packets that have a fragmentation problem. In the other direction you might load a small test page with small packets and no fragmentation problem.

Similarly, ssh might work when you're doing small things but then if you do something that results in a lot of text being sent, the packet size grows and now you have the fragmentation issue again.

graciejane

Hey thanks for that. Yeah I've been reading about packet size and MTU related issues. Thing is, mine either work perfectly or not at all, consistently. There's nothing intermittent about it. This is an SSH connection attempt (with a ping thrown in for good measure):

Pinging 10.16.3.20 with 32 bytes of data:
Reply from 10.16.3.20: bytes=32 time=244ms TTL=61
Reply from 10.16.3.20: bytes=32 time=261ms TTL=62
Reply from 10.16.3.20: bytes=32 time=243ms TTL=62
Reply from 10.16.3.20: bytes=32 time=246ms TTL=62

Ping statistics for 10.16.3.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 243ms, Maximum = 261ms, Average = 248ms

C:\Users\grace>ssh grace@10.16.3.20
ssh: connect to host 10.16.3.20 port 22: Connection timed out

I think I might have to learn how to use wireshark.

graciejane

Wireshark has revealed the problem. Packets are arriving with incorrect checksums when the following conditions are met:

Protocol is TCP
The packet must pass through the IPsec tunnel in a particular direction
The source OS is Linux (possibly a particular kernel, don't know)

Change any of those three things and the checksums are good.

The 3-way handshake is failing because my PC is not responding to the SYN-ACK packets with bad checksums.

This is what good looks like (HTTP server running on Windows):

So now I know what's happening, but not why. Not sure what to try from here.

scurrier

@graciejane wow, well done. I can't imagine what the cause could be.

graciejane

I'm baffled too. I need to put this down for now as have other priorities. Maybe coming back to it with a fresh mind after a few days will help.

scurrier

FYI, my issue turned out to be this IPsec Advanced Setting on my SG-1100:

The time I wasted to find out that that checkbox might as well say " break my SH!# "...

graciejane

Good to hear you found the problem.

I solved my one too. The OS being Linux wasn't actually one of the required conditions, but it was a big clue. The real problem was the type of virtual NIC (the remote hosts are KVM virtual machines). The default NIC for Linux is VirtIO vs an emulation of a real NIC - the Intel E1000 - for Windows. Swap out the VirtIO for an E1000 on the Linux hosts and problem solved!

mkit

@scurrier That check box caused me some issues as well. Thanks for sharing. My Netgate could connect to my Sonicwall but not from Sonicwall to Netgate.

taxiarxos

Hello All,

I am having exactly the same issue but when I enable or disable this check box at VPN IPSec Advanced I am still not able to use ssh or http/https. Any other ideas?

Thank you in advance.