Bug 145846 - problem with netfilter and ipsec
Summary: problem with netfilter and ipsec
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-22 08:56 UTC by E. Lefty Kreouzis
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-29 08:17:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gateway iptables configuration (1.55 KB, text/plain)
2005-01-22 08:58 UTC, E. Lefty Kreouzis
no flags Details

Description E. Lefty Kreouzis 2005-01-22 08:56:10 UTC
Description of problem:

There is a problem with the FC3 kernel kernel-2.6.10-1.741_FC3
The problem doesn't appear when booting with kernel-2.6.9-1.681_FC3

I have created an IPSEC tunnel between two networks over the internet.

When I try to ping a host in the internal network I have a problem
because the ipsec gateway (running FC3) doesn't forward the ICMP echo
reply packet.

The packet is received in the outside interface (as shown by the
tcpdump logs)
showing the ESP encapsulated icmp echo request and the reply packet.

10:45:32.952817 IP >
10:45:33.043123 IP >
10:45:33.043123 IP > icmp 64: echo reply seq 71

however from the internal network we only get the ICMP echo request:

10:48:37.964391 IP > icmp 64: echo request seq 256
10:48:38.963640 IP > icmp 64: echo request seq 257
10:48:39.963499 IP > icmp 64: echo request seq 258
10:48:40.963390 IP > icmp 64: echo request seq 259

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.741_FC3 problem
kernel-2.6.9-1.681_FC3 OK

How reproducible:

Steps to Reproduce:
1. Boot with kernel-2.6.10-1.741_FC3
2. create an ipsec tunnel between two networks
3. ping from the inside of one network to the inside of the other network
4. verify that ping fails to work

Actual results:

ping fails, ICMP echo reply are NOT forwarded

Expected results:

ping works, ICMP echo reply ARE forwarded

Additional info:

Comment 1 E. Lefty Kreouzis 2005-01-22 08:58:25 UTC
Created attachment 110088 [details]
gateway iptables configuration

Comment 2 E. Lefty Kreouzis 2005-01-22 09:03:42 UTC
The problem exists also withe the following simple iptables configuration:

# Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005
:PREROUTING ACCEPT [35788:8346069]
:INPUT ACCEPT [17225:1329797]
:FORWARD ACCEPT [15377:6749388]
:OUTPUT ACCEPT [13496:2656364]
:POSTROUTING ACCEPT [28823:9531852]
# Completed on Sat Jan 22 11:01:47 2005
# Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005
:INPUT ACCEPT [162:13225]
:OUTPUT ACCEPT [102:16280]
# Completed on Sat Jan 22 11:01:47 2005
# Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005
:PREROUTING ACCEPT [2151:189759]
:OUTPUT ACCEPT [33:3432]
# Completed on Sat Jan 22 11:01:47 2005

Comment 3 Trevor Cordes 2005-03-02 14:21:40 UTC
I'm seeing something like this also.  At first I thought it was my routing
tables or my iptables, but I've quickly exhausted every fix and test case I can
think of. 

I too have a working setup with 2.6.9-1.681 (patched to handle the ipsec/NAT bug).

I'm attempting to make another setup where both sides are (again
patched to handle the ipsec/NAT bug) and weird stuff is happening:

1. ping gateway to gateway WORKS (I have both a tunnel and transport setup)
2. ping gateway to remote host FAILS -- the ping gets encapsulated and sent to
the remote gateway and there enters PREROUTING chain and then is dropped/lost
for no apparent reason
3. ping host to remote host FAILS -- generates ICMP dest_unreach net_unreach on
local gateway.  Doesn't generate any traffic over the ipsec link.  This may be a
routing issue, but my routing is simple and I'm pretty sure it is correct (works
on 2.6.9).

I'll do more testing on 2.6.10 and check out some other bugs and report back.

Comment 4 Trevor Cordes 2005-03-02 14:28:02 UTC
duplicate of 145773 ?  Fix is try ipsec-tools-0.5-rc1?  I'll test that out.

145507 could possibly be related.  Looks like new semantics for us folk doing
manual setkey stuff.  Must add fwd spd's.  This sounds most promising.

Comment 5 Trevor Cordes 2005-03-02 14:44:26 UTC
Ta-da!  It's magic!  Add yourself some matching -P fwd rules for every -P in
spdadd you do with setkey.

Definitely this is a usage issue "feature" that changed between 2.6.9 and
2.6.10.  I'm not sure how a newer ipsec-tools would help, unless it
automatically adds fwd's for every in?  That would not really make sense.

This bug will hit anyone who has a working MANUALLY CONFIGURED 2.6.9 ipsec setup
and then upgrades to 2.6.10.  It will just stop working for most packet
traversal cases.  Hopefully they will see this and not waste 3 hours
troubleshooting like I did!

If you use the (redhat specific?) ifup-ipsec scripts then the next version will
probably fix the problem automatically for you (ala bug 145507).

So this bug isn't really a bug as there's really nothing to fix (on the vendor

Comment 6 Dave Jones 2005-07-15 20:19:44 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 7 Trevor Cordes 2005-10-03 12:34:37 UTC
Note, as per other bugs on this subject, the newer ipsec-tools and/or other
packages have this problem fixed so you don't need to manually add fwd rules
anymore.  So this bug was just a transient problem.  As of ipsec-tools-0.5-2.fc3
the behaviour should be the same as it originally was.

Also note, adding the fwd rules anyways didn't seem to hurt anything, even with
the updated packages.  Don't quote me on that though.

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