Bug #6167
open
IPsec IPComp not working
Added by Chris Buechler over 8 years ago. Updated 11 months ago.
0%
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.
Updated by Jim Thompson over 8 years ago
- Assignee set to George Neville-Neil
Assigned to gnn, in case it's related to tryforward.
Updated by Chris Buechler over 8 years ago
I'm testing stock FreeBSD 10.3 and will report back.
Updated by George Neville-Neil over 8 years 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.
Updated by Chris Buechler over 8 years ago
- Status changed from Confirmed to Feedback
Pulled in the patch on https://reviews.freebsd.org/D6062 which gnn has confirmed fixes the issue.
Updated by Ronald Antony over 8 years ago
Is this already in the snapshots? Last I checked dataflow is still blocked when I enable IPComp...
Updated by Chris Buechler over 8 years ago
- Status changed from Feedback to Confirmed
patch broke the build of cryptostats so was reverted.
Updated by Chris Buechler over 8 years 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.
Updated by Chris Buechler over 8 years 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.
Updated by Ronald Antony over 8 years 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.
Updated by Chris Buechler over 8 years ago
- Target version changed from 2.3.2 to 2.4.0
- Affected Version changed from 2.3 to 2.3.x
Updated by Jim Pingle over 7 years ago
- Target version changed from 2.4.0 to 2.4.1
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.1 to 2.4.2
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.2 to 2.4.3
Updated by Jim Pingle almost 7 years ago
- Target version changed from 2.4.3 to 2.4.4
Updated by Ronald Antony over 6 years ago
Is there any progress on this, other than that the target version moves to the next version each time a new version is released? :D
It would improve my network throughput quite a bit, since I'm on a bandwidth limited link...
Updated by Jim Pingle about 6 years ago
- Target version changed from 2.4.4 to 2.4.4-GS
Updated by Jim Pingle about 6 years ago
- Target version changed from 2.4.4-GS to 48
Updated by Ronald Antony over 5 years ago
Is this actually ever going to happen? For three years now, this is just moving from one release to the next, without visible progress, meanwhile, it would improve things were it done...
Updated by Adam Gibson about 5 years ago
I have this enabled with other firewall solutions and observed noticeable savings in bandwidth usage. I was hoping to enable this for a site seeing unexpected increase in traffic but it looks like it doesn't work yet with pfsense. Is there a workaround to get IPcomp working?
Updated by Ronald Antony almost 5 years ago
Ping, Ping, Ping...
Is this thing working? It's been well over three years, different IPSec, kernel, BSD version,...
...and nothing?
Is this ever going to get any attention? I could use the bandwidth savings...
Updated by Ronald Antony over 4 years ago
Seeing that 2.5 is progressing, any chance this will finally make it?
Not sure what sort of wide, bandwidth-is-no-issue nets you all are working with, but I have a limited bandwidth and a monthly data limit, so any bit of extra performance and data cap I can squeeze out of the VPN is more than just "nice to have".
Updated by Renato Botelho about 4 years ago
- Target version changed from 2.5.0 to Future
When it's fixed on FreeBSD we can import the fix and target it to a version
Updated by Ronald Antony over 1 year ago
Renato Botelho wrote in #note-25:
When it's fixed on FreeBSD we can import the fix and target it to a version
Is there any chance they are actually going to work on it? Is the FreeBSD team even aware of the problem, i.e. is it in their bug tracker? (If so, where?)
Even if IPComp isn't working (as it should), at the very least it never should just silently fail....
Thanks!
Updated by Marcos M 11 months ago
- Assignee deleted (
George Neville-Neil)
Some basic testing on 23.09.1 shows it works for policy-based tunnels, but not for route-based tunnels (VTI). Here's a test patch to try it out (enabled under IPsec Advanced Settings and per Phase 2): ShowHide
diff --git a/src/etc/inc/ipsec.inc b/src/etc/inc/ipsec.inc
index 44f3d85edc..82facd8809 100644
--- a/src/etc/inc/ipsec.inc
+++ b/src/etc/inc/ipsec.inc
@@ -2597,6 +2597,9 @@ function ipsec_setup_tunnels() {
$child = array();
$local_ts = "";
$remote_ts = "";
+ if (isset($ph2ent['compression'])) {
+ $child['ipcomp'] = isset($ph2ent['compression']) ? 'yes' : 'no';
+ }
if (($ph2ent['mode'] == 'tunnel') or ($ph2ent['mode'] == 'tunnel6')) {
/* Normal tunnel child config */
$child['mode'] = "tunnel";
@@ -3188,12 +3191,9 @@ function ipsec_configure($restart = false, $filterdns_restart = false) {
if (array_key_exists(config_get_path('ipsec/uniqueids', ""), $ipsec_idhandling)) {
$conn_defaults['unique'] = config_get_path('ipsec/uniqueids');
}
- /* Disable ipcomp for now. redmine #6167
- if (isset($config['ipsec']['compression'])) {
- $conn_defaults['compress'] = "yes";
- }
- set_single_sysctl('net.inet.ipcomp.ipcomp_enable', (isset($config['ipsec']['compression'])) ? 1 : 0);
- */
+ /* Disable ipcomp for now. redmine #6167 */
+ set_single_sysctl('net.inet.ipcomp.ipcomp_enable', (config_path_enabled('ipsec', 'compression')) ? '1' : '0');
+
/* End Global Connection Defaults */
/* Start swanctl configuration (scconf) */
diff --git a/src/usr/local/www/vpn_ipsec_phase2.php b/src/usr/local/www/vpn_ipsec_phase2.php
index 0773faa1b1..cbc3d488fe 100644
--- a/src/usr/local/www/vpn_ipsec_phase2.php
+++ b/src/usr/local/www/vpn_ipsec_phase2.php
@@ -72,6 +72,7 @@ if ($p2index !== null) {
$pconfig['ikeid'] = $ph2['ikeid'];
$pconfig['disabled'] = isset($ph2['disabled']);
$pconfig['mode'] = $ph2['mode'];
+ $pconfig['compression'] = isset($ph2['compression']);
$pconfig['descr'] = $ph2['descr'];
$pconfig['uniqid'] = $ph2['uniqid'];
@@ -421,6 +422,7 @@ if ($_POST['save']) {
$ph2ent['uniqid'] = $pconfig['uniqid'];
$ph2ent['mode'] = $pconfig['mode'];
$ph2ent['disabled'] = $pconfig['disabled'] ? true : false;
+ $ph2ent['compression'] = $pconfig['compression'] ? true : false;
if (!isset($pconfig['reqid'])) {
$ph2ent['reqid'] = ipsec_new_reqid();
} else {
@@ -592,6 +594,13 @@ $section->addInput(new Form_Select(
$p2_modes
));
+$section->addInput(new Form_Checkbox(
+ 'compression',
+ 'IP Compression',
+ 'Enable IP compression.',
+ $pconfig['compression']
+));
+
if (!empty($pconfig['ikeid'])) {
$p1 = ipsec_get_phase1($pconfig['ikeid']);
if (!empty($p1['descr'])) {
Additional testing is needed such as with different (ESP/AH), algorithm types (-GCM and non -GCM), accelerators (IIMB/QAT/AES-NI), and filtering modes (VTI/tunnel).