Bug 58497 - iptables won't DNAT outgoing TCP connections correctly
iptables won't DNAT outgoing TCP connections correctly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-17 23:50 EST by Alexandre Oliva
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:20 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)

  None (edit)
Description Alexandre Oliva 2002-01-17 23:50:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Description of problem:
When an IP alias is created on a machine, taking a previously-unused IP address
in the same subnet as that of the primary IP address assigned to the network
interface, and attempts are made to divert output packets addressed to this IP
to another machine, UDP packets are handled correctly, but TCP connections are
not, and ping does not see ICMP echo replies even though they get back to the
originating machine.

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

How reproducible:
Always

Steps to Reproduce:
1.in your local subnet in device DEV, with netmask NM and broadcast address BC,
choose an unused IP address say UIP; call LIP the IP primary IP address of your
machine in this subnet, and RIP the IP address of another machine in the same
subnet on interface RDEV, preferably some machine running named and sshd
2.ifconfig $DEV:0 $UIP netmask $NM broadcast $BC # optional; does not affect the
outcome
3.iptables -t nat -A OUTPUT -d $UIP -j DNAT --to $RIP
4.iptables -t nat -A POSTROUTING -d $UIP -j SNAT --to $LIP # optional, unless #2
is put in
5.tcpdump -i $DEV
6.on the console of $RIP (unless you want to ssh to it and filter the
communication out using ! port <port#>), run tcpdump -i $RDEV
7.ping $UIP
8.host $LIP $UIP
9.ssh -v $UIP

Actual Results:  ping will not acknowledge the receipt of the reply packets that
tcpdump reports on both ends

host will work correctly, obtaining information from RIP

ssh will establish a connection, but tcpdump on RIP reports packets incoming
from two different LIP ports for the same connection: the first packet with the
original outgoing port (32000+), as chosen by the ssh client, and the second one
low (1024 or so), chosen by iptables for SNATing.  The proof that they both
belong to the same connection is that the TCP sequence numbers are consecutive,
and whenever $RIP sends a connection ack to the high port number, it gets an ack
back from the low port number.

Expected Results:  ICMP and TCP connections should work in this scenario, I believe.


Additional info:

I have tried to limit SNATting based on the source address without success.  I
could get ping to work, even though it reported it got packets back from RIP
instead of from UIP as it should, but no success with ssh.
Comment 1 Bugzilla owner 2004-09-30 11:39:20 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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