Project

General

Profile

Issue #2478

Compression not working

Added by Olaf Martens almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Affected version:
5.6.0
Resolution:
No feedback

Description

StrongSwan 5.6.0 (strongswan-ipsec-5.6.0-2.1) running on a Linux kernel 4.11.1-1.4 has problems compressing IPsec traffic. Some time after upgrading things (I'm using openSuSE Tumbleweed) any IPsec connections failed without any sign on what could have gone wrong, both linking from my box using strongswan-nm to a server and between the two servers that I have linked via StrongSwan.

My first try switching from type=tunnel to type=transport didn't help, but after disabling compression things started working again. Checking the kernel revealed that the deflate module is loaded, and zlib is available as well (/lib64/libz.so.1.2.11).

What could be going wrong here?

History

#1 Updated by Tobias Brunner almost 3 years ago

  • Status changed from New to Feedback

Some time after upgrading things

Upgrading what exactly? strongSwan? Kernel? Both?

What could be going wrong here?

No idea. The test scenarios that use compression seem to work fine (5.6.1 on a 4.10 kernel): ikev2/compress, ikev2/compress-nat. You'll need to look closer at the SAs (e.g. packet counters) and perhaps any Netfilter rules you have installed (if you don't use the default updown script you might need to manually allow IPIP traffic, see IPComp).

#2 Updated by Michael Tremer over 2 years ago

Hello,

I can confirm that this is an issue with kernel 4.14 and it looks like some other kernels as well where this problem has been backported to (see OP for OpenSUSE).

We at IPFire are tracking this issue over here https://bugzilla.ipfire.org/show_bug.cgi?id=11550. It has also been raised on the mailing list https://lists.strongswan.org/pipermail/users/2017-December/011941.html.

What we know so far is that packet counters stay at zero and not a single packet is being encrypted and being sent out. Also not unencrypted because it is missing any policies or so. Firewall rules should be fine for IPIP and remain untouched. Only the kernel is being replaced.

Any ideas where to start looking? The step from 4.13 to 4.14 is too large for me to bisect. IPComp has not been touched in years in the mainline kernel.

#3 Updated by Tobias Brunner over 2 years ago

Any ideas where to start looking? The step from 4.13 to 4.14 is too large for me to bisect. IPComp has not been touched in years in the mainline kernel.

Yes, 4.14 before 4.14.12 is broken when it comes to certain transport mode SAs, which is the case if IPComp is used (the IPComp SA is tunnel/transport mode, as negotiated, the IPsec SA always transport mode). The commit that fixed the issue is 94802151894d482e82c324edf2c658f8e6b96508, which, as mentioned, was included in 4.14.12.

#4 Updated by Michael Tremer over 2 years ago

Thanks for replying so quickly. However, I did not get an email notification. Any idea why? Notifications are enabled for my account.

Thanks for letting me know. I have 4.14.13 built here and can confirm it actually seems to be working again.

I guess this ticket can be closed then.

#5 Updated by Tobias Brunner over 2 years ago

However, I did not get an email notification. Any idea why? Notifications are enabled for my account.

You are neither the author nor a watcher of this issue. Just adding a comment to an issue apparently does not get Redmine to send you notifications about it, unless, you enable notifications for all events, but I don't recommend that (there is an open issue regarding this).

I guess this ticket can be closed then.

Not sure if the original author thinks it's fixed, he used a 4.11 kernel.

#6 Updated by Tobias Brunner over 2 years ago

  • Category set to kernel
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No feedback

Also available in: Atom PDF