Bug 159116

Summary: netfilter/NAT broken with IPSec tunnel
Product: Red Hat Enterprise Linux 4 Reporter: Yue Shi Lai <ylai>
Component: kernelAssignee: David Miller <davem>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: davej, oliver, uwe.knop
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 13:24:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch for to get IPSec+NAT patches compile with RHEL4 kernel none

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
ipsec-tools-devel.net:

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 2.6.16.18 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.