Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 145846 - problem with netfilter and ipsec
problem with netfilter and ipsec
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2005-01-22 03:56 EST by E. Lefty Kreouzis
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 04:17:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 03:58 EST, E. Lefty Kreouzis 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description E. Lefty Kreouzis 2005-01-22 03:56:10 EST 
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 213.16.151.39 > 62.38.193.194:
ESP(spi=0x0afc9507,seq=0xb) 
10:45:33.043123 IP 62.38.193.194 > 213.16.151.39:
ESP(spi=0x0ab64ab7,seq=0xb)
10:45:33.043123 IP 192.168.0.4 > 10.3.0.8: icmp 64: echo reply seq 71

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

10:48:37.964391 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 256
10:48:38.963640 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 257
10:48:39.963499 IP 10.3.0.8 > 192.168.0.4: icmp 64: echo request seq 258
10:48:40.963390 IP 10.3.0.8 > 192.168.0.4: 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 03:58:25 EST 
Created attachment 110088 [details]
gateway iptables configuration
Comment 2 E. Lefty Kreouzis 2005-01-22 04:03:42 EST 
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
*mangle
:PREROUTING ACCEPT [35788:8346069]
:INPUT ACCEPT [17225:1329797]
:FORWARD ACCEPT [15377:6749388]
:OUTPUT ACCEPT [13496:2656364]
:POSTROUTING ACCEPT [28823:9531852]
COMMIT
# Completed on Sat Jan 22 11:01:47 2005
# Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005
*filter
:INPUT ACCEPT [162:13225]
:FORWARD ACCEPT [48:4032]
:OUTPUT ACCEPT [102:16280]
COMMIT
# Completed on Sat Jan 22 11:01:47 2005
# Generated by iptables-save v1.2.11 on Sat Jan 22 11:01:47 2005
*nat
:PREROUTING ACCEPT [2151:189759]
:POSTROUTING ACCEPT [1069:144712]
:OUTPUT ACCEPT [33:3432]
-A POSTROUTING -s 10.3.0.0/255.255.255.0 -o ippp0 -j MASQUERADE
COMMIT
# Completed on Sat Jan 22 11:01:47 2005
Comment 3 Trevor Cordes 2005-03-02 09:21:40 EST 
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 2.6.10.766_FC3 (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 09:28:02 EST 
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 09:44:26 EST 
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
side).
Comment 6 Dave Jones 2005-07-15 16:19:44 EDT 
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 08:34:37 EDT 
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.
First Last Prev Next    This bug is not in your last search results.