IPCompression stops IPSec traffic

  • We have two 2.2.6 x64 pfSense firewalls connected successfully with public IPs (no double-NATing) over IPv4 via IKEv2 and AES256 (P1 and P2).  Traffic is flowing normally.  :)

    Turning on IPCOMP (under Advanced Settings > IP Compression) breaks all VPN traffic (of course, turning on just one side is fine, but it breaks when both sides are checked and IPCOMP is actually proposed and used).  The tunnel builds instantly, but no traffic is forwarded.  :(

    The case is pretty much the same as this old, unresolved post: https://forum.pfsense.org/index.php?topic=99841.msg556270#msg556270 with the exception BOTH sides of our network are pfSense; there is no other third-party firewall or different version of IPCOMP involved.

    Is this a known issue?

    We've tried with numerous possibilities, including IKEv1, DES, etc.  In all cases, it is only the IPCOMP that breaks the link; VPNs work perfectly in other scenarios.  :o

    It would be great to know if this should be opened as a bug or if we're doing something silly.

  • Same here…
    On 2.3

  • I've done some more testing.  I'm super interested to know if other people obtain the same results.

    Basically, I can get a connection working with IPCOMP turned on when Nat-T is forced (IKE v.1).  This seems to be a bug because disabling IPCOMP and putting Nat-T back to auto (StrongSwan apparently has no disable option  >:( ) breaks the IPSec connection and I haven't been able to get it back, even with changing all the settings and refreshing the services…so once Nat-T is forced in pfSense, the system somehow remembers it and forces it on even in IKE v.2 in networks where it is not appropriate.  :-*

    I'm happy to see IPCOMP working, but in my preliminary tests (no hard data), it has not improved throughput even with compressible data.  I've tested with pfSense boxes running super-duper 3.5GHz Xeons as well as an Atom-based box.

Log in to reply