Project

General

Profile

Bug #6167

IPsec IPComp not working

Added by Chris Buechler about 1 year ago. Updated 10 months ago.

Status:
Confirmed
Priority:
Normal
Category:
IPsec
Target version:
Start date:
04/15/2016
Due date:
% Done:

0%

Affected version:
2.3.x
Affected Architecture:

Description

IPsec connections that enable IPComp end up unable to pass traffic. Egress traffic goes out, ingress comes in, byte counters increment accordingly. Traffic is seen in tcpdump on enc0. But the traffic never makes it past enc0 on ingress. No apparent errors or anything. Multiple users have confirmed, and it's easily replicable by setting up a site to site VPN, verifying it works, then enabling IPComp on both sides.

Associated revisions

Revision c7759e4e
Added by Chris Buechler 12 months ago

Disable ipcomp regardless of config setting to avoid problem. Ticket #6167

Revision a23600ef
Added by Chris Buechler 12 months ago

Disable ipcomp regardless of config setting to avoid problem. Ticket #6167

History

#2 Updated by Jim Thompson about 1 year ago

  • Assignee set to George Neville-Neil

Assigned to gnn, in case it's related to tryforward.

#3 Updated by Chris Buechler about 1 year ago

I'm testing stock FreeBSD 10.3 and will report back.

#4 Updated by George Neville-Neil about 1 year ago

Test and config pushed here: https://github.com/gvnn3/netperf/tree/master/IPSEC/Tests/iperf-null-ipcomp-nopmc

What I'm seeing is that ipcomp doesn't work at all even in the absence of ESP etc. I'm digging into this now.

#5 Updated by Chris Buechler about 1 year ago

It works fine on stock FreeBSD 10.3.

#6 Updated by Chris Buechler about 1 year ago

  • Status changed from Confirmed to Feedback

Pulled in the patch on https://reviews.freebsd.org/D6062 which gnn has confirmed fixes the issue.

#7 Updated by Ronald Antony about 1 year ago

Is this already in the snapshots? Last I checked dataflow is still blocked when I enable IPComp...

#8 Updated by Chris Buechler 12 months ago

  • Status changed from Feedback to Confirmed

patch broke the build of cryptostats so was reverted.

#9 Updated by Chris Buechler 12 months ago

Luiz merged the upstream fix for this in 384ae63efc9d676414c45591c9b6095197919513. With the note: "I changed the IPv6 part to use struct ip6protosw and wrote a wrapper for v4 version of ipcomp_nonexp_input()"

latest snapshot with that change exhibits the same behavior. Large packets are fine, small ones are dropped.

#10 Updated by Chris Buechler 12 months ago

  • Target version changed from 2.3.1 to 2.3.2

We'll leave this as-is for 2.3.1 to avoid introducing any regressions for something that's little-used and off by default. I just pushed a change to not enable ipcomp regardless of config to prevent hitting the issue for 2.3.1.

#11 Updated by Ronald Antony 11 months ago

Chris Buechler wrote:

We'll leave this as-is for 2.3.1 to avoid introducing any regressions for something that's little-used and off by default. I just pushed a change to not enable ipcomp regardless of config to prevent hitting the issue for 2.3.1.

I understand everything you wrote, except for the “little-used” part. Been using this on just abøut every platform that supports it for years, and most of the time it results in a performance increase well worth checking an option…
…frankly, I wonder why that’s even an option.

Anyway, main point I’m trying to make: it’s being used, so please don’t forget about it….

Also: the current band-aid fix only works when there’s pfSense on both sides of the connection, because generally a connection is only established when the options agree, and if pfSense ignores the setting, but the other side does not, the connection still won’t work and people will pull their hair…

BTW: the release notes for the 3.2 releases don’t list open issues, you could probably save a lot of people hassle and take traffic off the forums, if the release notes would list known issues, not just issues fixed, that way there’s a first document to check if things don’t behave as expected. Took me a while to find the IPComp issue after upgrading to 2.3, since the issue was listed in the blog, but not the release notes.

#12 Updated by Chris Buechler 10 months ago

  • Target version changed from 2.3.2 to 2.4.0
  • Affected version changed from 2.3 to 2.3.x

Also available in: Atom PDF