Red Hat Bugzilla – Bug 159116
netfilter/NAT broken with IPSec tunnel
Last modified: 2012-06-20 09:24:10 EDT
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):
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
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
5. Insert a "-o <outgoing-interface> -j MASQUERADE" or similar SNAT chain in the
iptables "nat" table.
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.
Ping to outside hosts should work, packets should go through the "nat" table and
have their source IP translated when leaving the outgoing interface.
Created attachment 114960 [details]
Patch for to get IPSec+NAT patches compile with RHEL4 kernel
It seems that this might in fact being an issue with IPSec, iptables, and a
bridge device. See e.g.:
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."
Cut and paste from a message from 18.01.2006 on
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.
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
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
I tested the behaviour both with and without CONFIG_BRIDGE_NETFILTER=y using
RHEL 4 running the stock 188.8.131.52 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?
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.
The solution is to upgrade to RHEL5 or there will be a patch for kernel 2.6.9?
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.
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.