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.