<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: options config...
From: Marco Palumbi <marco.palumbi,AT,tiscali,DOT,it>
Date: Thu, 13 Feb 2003 17:45:03 +0100
In-reply-to: <7DB0958915FDD611961400A0C98F18460BCE76@WINTRIX.thermeon.com>

Amith Varghese wrote:
> 
> > What you're seeing is the normal behavior of NAT.  When a UDP packet
> > is directed through a NAT it's source address is modified to that of the 
>NAT
> > system and it is sent along it's way, when a response returns the NAT 
>system
> > must consult it's UDP list and remember where the response should be
> > directed.   The NAT table is only short-lived.  I believe that Windows ICS
> > only has a 60 second time-out.    On my systems I keep a 30 second ping
> > going from behind a NAT firewall to an external system with a static 
>address.
> 
> Linux A--------NAT/Firewall---| Internet |-----------Linux B
> 

the problem is the port translation - PAT (port address translation)
 
The NAT/Firewall translates the port address of the udp packet outgoing from 
the
linux A.
The  association of the original port in the linux A to the translated port 
from
the NAT/Firewall remain valid for some time of inactivity (say 60 sec's) after
while if linux A sends a new packet it is translated to a new address.

during this time a packet sent to NAT/Firewall at the translated address port 
is
sent to Linux A to the original port.

The key is that every time Linux B receives a packet from e new port it 
remember
this port and will use this for the answer to Linux A

So consider the scenario

cipe on linux A use port 6000

NAT/Firewall map port 6000 to port 6000 of linux A

cipe on Linux B use port 6000

linux B start sending a packet from its port 6000 to NAT/Firewall port 6000

NAT/Firewall send the packet to Linux A port 6000

Linux A answer sending a packet from its port 6000 to Linux B port 6000

when the packet cross the NAT/Firewall will be translated to we say port 10000

Linux B sees the port changed to 10000 and will answer to this port so:

Linux B answer sending a packet from its port 6000 to NAT/Firewall port 10000

NAT/Firewall send the packet to Linux A port 6000

if you stop the traffic for more of 60 sec's NAT/Firewall will forget the
association port 10000<->port 6000

so if Linux B send a new packet he will send to port 10000 but the association
is now no longer valid....

in such a scenario could be better not to have the cipe feature of port 
tracking
on Linux B.
For a similar problem i hacked the code of cipe.
The best thing would be to have an option for turning of this behavior .

Marco





<< | Thread Index | >> ]    [ << | Date Index | >> ]