|Summary:||netfilter/NAT broken with IPSec tunnel|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Yue Shi Lai <ylai>|
|Component:||kernel||Assignee:||David Miller <davem>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||davej, oliver, uwe.knop|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-06-20 13:24:10 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Yue Shi Lai 2005-05-30 05:28:38 UTC
Description of problem: This problem is partially related to Bug 143374. However, even with the 4 IPSec+NAT patches applied, netfilter/iptables still fails to perform SNAT/ masquerade on IPSec tunneling packets. Specifically, ethereal shows that the tunneling packets are decrypted and leaving the NATed network interface using unchanged source IP. Inserting "-j LOG" into iptable chains shows the packets apparently never reach the "nat" table, but only "mangle" and "filter". The same configuration using Red Hat Enterprise Linux 3 works. Version-Release number of selected component (if applicable): kernel-2.6.9-5.0.5.EL How reproducible: always Steps to Reproduce: 1. Apply the 4 IPSec+NAT patches (see Bug 143374, and for RHEL4 kernel source, you need to change make xfrm_policy_get_afinfo, xfrm_policy_put_afinfo, see the attached patch). 2. Establish a IPSec tunnel, check that ping to the host works and the packets are in fact ESP/AH packets. 3. Turn on "net.ipv4.ip_forward = 1". 4. Insert a "-j LOG" chain in each of "mangle", "filter", and "nat" iptables table. 5. Insert a "-o <outgoing-interface> -j MASQUERADE" or similar SNAT chain in the iptables "nat" table. Actual results: Ping to (ping responding) hosts attached to the outgoign interface fails, Ethereal shows packets are going out using unmodified source IP. Iptables log shows packets goes through "mangle", "filter", but never reach the "nat" table. Expected results: Ping to outside hosts should work, packets should go through the "nat" table and have their source IP translated when leaving the outgoing interface. Additional info:
Comment 1 Yue Shi Lai 2005-05-30 05:28:38 UTC
Created attachment 114960 [details] Patch for to get IPSec+NAT patches compile with RHEL4 kernel
Comment 2 Yue Shi Lai 2005-10-02 16:38:01 UTC
It seems that this might in fact being an issue with IPSec, iptables, and a bridge device. See e.g.: http://www.shorewall.net/IPSEC-2.6.html Quote: "As of this writing, the Netfilter+ipsec and policy match support are broken when used with a bridge device. The problem has been reported to the responsible Netfilter developer who has confirmed the problem."
Comment 3 Yue Shi Lai 2006-03-08 23:19:47 UTC
Cut and paste from a message from 18.01.2006 on firstname.lastname@example.org: Chinh Nguyen wrote: > > Does anyone know the correct configuration to allow IPSec in tunnel mode on a > > linux (Ubuntu 2.6.12) to work over NAT? Netfilter IPsec handling was broken until recently. The first kernel to properly handle this is 2.6.16-rc1.
Comment 4 Yue Shi Lai 2006-05-25 16:46:49 UTC
I think this bug (provided netfilter in the RHEL kernel is patched for IPSec+NAT) and also 179890 might be related to a very trivial kernel configuration problem. The comments on https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=400 suggests that with CONFIG_BRIDGE_NETFILTER=y in kernel configuration, the corresponding hooks might intercept the ESP/AH packages before the traverse properly through netfilter. Also the conntrack itself is closely related to SNAT/MASQUERADE. I tested the behaviour both with and without CONFIG_BRIDGE_NETFILTER=y using RHEL 4 running the stock 184.108.40.206 kernel (which includes the IPSec+NAT patches in netfilter), and it shows exactly the suggested behaviour: with CONFIG_BRIDGE_NETFILTER=y the packages leaves the outgoing device without SNAT/ MASQUERADE, witout it works properly. I yet need to test applying the IPSec+NAT patch against the RHEL kernel and also disable CONFIG_BRIDGE_NETFILTER=y, which might solve this bug and 179890. Is there any specific reason why Red Hat chose to activate this kernel flag?
Comment 5 Yue Shi Lai 2006-05-26 17:52:23 UTC
Correcto to the last comment: It turns out kernel 2.6.9-34.0.1.EL plus the 4 netfilter IPSec+NAT patches, and the additional patch undoing the XFRM symbol export removal is not sufficient to achieve correct NAT, even with CONFIG_BRIDGE_NETFILTER unset. It seems 2.6.16 contains more than the hooks implemented in the 4 patches.
Comment 6 Oliver Schulze L. 2007-07-12 14:22:16 UTC
Hi, The solution is to upgrade to RHEL5 or there will be a patch for kernel 2.6.9?
Comment 7 Yue Shi Lai 2007-07-12 14:38:24 UTC
I think the effort to backport the netfilter hooks from 2.6.16 would quite significant, with the amount of changes still too extensive for Red Hat to consider as a patch for RHEL4. An viable alternative for a RHEL4-based solution would be to use a stock 2.6.16 kernel with the side effect of losing SELinux.
Comment 8 Jiri Pallich 2012-06-20 13:24:10 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.