Bug 203433 - CONFIG_IXGBE_IPSEC forces IPsec offload
Summary: CONFIG_IXGBE_IPSEC forces IPsec offload
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-26 11:06 UTC by Gheorghe Ungureanu
Modified: 2019-04-26 11:10 UTC (History)
0 users

See Also:
Kernel Version: 5.0.9
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Gheorghe Ungureanu 2019-04-26 11:06:27 UTC
The IXGBE_IPSEC module doesn't check if the child SA has HW_ACCEL enabled or disabled, causing HW_ACCEL to be always enabled, even if, in some cases, there is no support for it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c?h=v5.1-rc6#n1085

There should be a check to see if the SA has HW_ACCEL or not, something like this: if (!xs->xso.offload_handle) return 1;

I noticed this when running StrongSwan within macvlan networks with Docker, on ArchLinux, on this nic: 82599ES 10-Gigabit SFI/SFP+ Network Connection. The connection is getting established and the packages are sent through the tunnel, but if the IPsec server has some form of NAT (masquerade or SNAT), packages don't get pushed out the 10 GbE device. This can be seen with `tcpdump -n -e -i interface icmp`:
21:51:17.575688 84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
21:51:17.575717 02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800), length 98: 139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
## Here a reply should be seen, but there is none. On further inspection we determined that packages are not sent out the interface, even if NAT can be seen in the tcpdump.

The solution to make IPsec work was to recompile the kernel without CONFIG_IXGBE_IPSEC (which is currently "y" by default on multiple distributions, so we can expect this problem to appear in the future). After this, NAT works for the IPsec connection and ICMP reply can be seen with tcpdump on the interface:
84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 10.201.0.1 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
02:42:8b:1c:d9:43 > 84:b5:9c:c5:77:00, ethertype IPv4 (0x0800), length 98: 139.28.217.67 > 9.9.9.9: ICMP echo request, id 10752, seq 1, length 64
84:b5:9c:c5:77:00 > 02:42:8b:1c:d9:43, ethertype IPv4 (0x0800), length 98: 9.9.9.9 > 139.28.217.67: ICMP echo reply, id 10752, seq 1, length 64

Steps to reproduce
1. create an IPsec connection, without HW offload (StrongSwan has it off by default, and it can also assign VIPs)
2. add masquerade for the VIPs, to go out the IXGBE nic.
3. tcpdump on the server and ping from the client

If I can help in any way on this case, please let me know.

Note You need to log in before you can comment on or make changes to this bug.