Bug 144797 - ipsec sends packets out wrong interface
Summary: ipsec sends packets out wrong interface
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 3
Hardware: i386 Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-11 16:49 UTC by Aaron Straus
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: ipsec-tools-0.5-0.fc3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-07 00:16:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Aaron Straus 2005-01-11 16:49:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)

Description of problem:
we have a fedora i386 hyperthreaded box routing between two interfaces
eth0 (external) and eth1 (internal).

we run ripd and have many firewall rules on the box.

in addition we run racoon and use this box as our IPSEC (tunnel mode)

as of 2.6.9-1.681 everything was fine.  Once upgrading to 2.6.9-1_724
we are noticing the following:

o   racoon negotiates the connection with the peer correctly.
o   packets are encrypted from our internal network fine and the peer
    receives them fine.
o   the peer responds and the packets are decrypted correctly.

o   _BUT_ the packets coming in have destination address on our 
    internal network so you'd expect them to go out on eth1.  
    However, as of the _724 kernel they go out on eth0???
    We can see this by doing a tcpdump...

If we reboot to 681 the problem disappers (packets go out on eth1).
We've checked the routing tables and it's clear the packet should
be destined to go out eth1.  

You can also ping an internal machine fine from this box and as you'd
expect the packet goes out eth1 so it seems to only be an IPSEC problem?

Anyway thanks.  We will try the latest kernel this afternoon to verify
the problem is still in 2.6.10-1.737_FC3.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  setup a router as described
2.  boot kernel 724
3.  try IPSEC

Actual Results:  decrypted packets destined for the internal network
leave eth0 despite a routing table that says they should leave eth1

Expected Results:  decrypted packets destined for the internal network
leave eth1

Additional info:

IPSEC is the only network related problem we are having... the
standard routing and firewall seems to be working normally.

Comment 1 Aaron Straus 2005-01-15 00:43:30 UTC
Tested this evening w/ latest fedora kernel:


the bug is still present.

Comment 2 Aaron Straus 2005-03-05 01:09:30 UTC
I believe upgrading to the latest ipsec-tools (ipsec-tools-0.5-0.fc3) solved
this with the most recent kernel.  I will test next week and respond here.  Many

Comment 3 Aaron Straus 2005-03-07 00:16:46 UTC
This indeed looks fixed by the ipsec-tools update.  Thank you!

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