IPsec - pfsense 2.2.4 - IPCompression causes IPsec failure
If anyone has any ideas regarding this issue I would appreciate your thoughts.
Host A (192.168.255.3) –-- (pfsense) ---- Internet -- (FW/Router) -- (Snapgear Router) ---- Host B (172.16.0.99)
There is a IPsec tunnel between pfsense and the Snapgear Router. The pfsense instance is a replacement for a previous router and so I just configured the IPsec tunnel with the same parameters as previously, which included IPCompression.
The Snapgear Router is behind a firewall so the IPsec traffic is NAT-T using UDP 4500. The IPsec tunnel is initiated by the Snapgear Router.
Under testing there is an interesting problem: I use telnet to connect from Host A to Host B - everything works file. Everying is fine, run 'ls -l', everything is OK. Then do nothing for 2 minutes, just leave the connection idle, and then type an 'ls -l' command. What happens is that you see the echo of the 'ls -l' and then nothing comes out of the telnet session.
Using various traces I determined the following:
- the TCP data with the output of 'ls -l' is leaving Host B and arriving at the Snapgear, in fact, during the period of 'no output' you can see the TCP retransmissions occurring correctly.
- the snapgear is generating UDP 4500 traffic corresponding to the TCP data.
- the UDP 4500 traffic is arriving at the pfsense on the WAN link.
- if I 'packet capture' the ipsec interface in pfsense the TCP data is present, and all the retransmissions etc.
- there is no sign of the TCP traffic on the local network link out of pfsense, the inbound UDP 4500 traffic just 'disappears' inside pfsense.
- there are no reports of dropped data in the pfsense firewall logs
A wireshark analysis of the data captured on the ipsec interface shows that there is no problem with the compression of the TCP data, the packet looks fine.
Eventually, I decided to experiment with the IPsec settings and I turn off the IPCompression for the tunnel. This involved no changes to pfsense, just disabling the IPCompression on the tunnel.
At this point the problem is completely solved. What used to be a repeatable test sequence no longer fails and the link appears to be working correctly.
A surface analysis of this suggests that for some reason the IPCompression traffic is not being forwarded out the local network interface by pfsense.
Is this a known issue?
Is there something I am doing incorrectly?
Another piece of information that may be related to this issue is that when the link has IPCompression turned on and is in the 'no output state' (ie. you have waited 2 minutes, typed 'ls -l', seen the echo of the 'ls -l' and then nothing else) the system as a whole will sit in this state for many minutes without anything appearing to happen. However, if you establish another, unrelated, TCP session (eg. start another telnet via the tunnel) the data that was 'being lost' immediately starts coming out of pfsense on the local network and the original telnet continues on.