Begin forwarded message: Date: Fri, 26 Apr 2019 11:06:27 +0000 From: bugzilla-dae...@bugzilla.kernel.org To: step...@networkplumber.org Subject: [Bug 203433] New: CONFIG_IXGBE_IPSEC forces HW_ACCEL https://bugzilla.kernel.org/show_bug.cgi?id=203433 Bug ID: 203433 Summary: CONFIG_IXGBE_IPSEC forces HW_ACCEL Product: Networking Version: 2.5 Kernel Version: 5.0.9 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: step...@networkplumber.org Reporter: gheor...@linux.com Regression: No 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. -- You are receiving this mail because: You are the assignee for the bug.
