[UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

Hi Yunhong,
 
 Here is an issue which severely restricts UDT.  (apparently)
 I have an existing send / recv file, which seems to not work in an environment where the requester is behind an IPTABLES nat and the responder is on the lan without any firewall.
 
 REQUEST DIRECTION
    CLIENT-A   -----> IPTABLES-NAT ---> SERVER
 RESPONSE DIRECTION (BROKEN)
    SERVER     ------> IPTABLES-NAT  -X->  CLIENT-A
 
 here the iptables-nat is not sending the response back to the client-A where the request should go, hence the communication is not established, and a UDT::Connect() returns an error.
 
 Apparently it looks like an iptables-nat configuration issue. So I wrote down a simple UDP based communication from client-A to server and which works OK. SO, I turned to the ehthereal captures.. and here is what I got..
 
 Here is the setup
 Server listens on port 9800 with IP 192.168.0.78.
 client-A is behind a iptables-nat and has the 172.16.54.11 address.
 Nats public interface is 192.168.0.100 and internal interface is 172.16.54.1
 
 1. CLIENT-A : -->  172.16.54.11:1456 --> 192.168.0.78:9800
 2. NAT : <-- 172.16.54.11:1456  -->  172.16.54.1:9788
 3. NAT:  --> 192.168.0.100:9788 --> 192.168.0.78:9800
 4. SERVER: --> 192.168.0.78:13221 --> 192.168.0.100:9788
 5. NAT: <-- Rejects, as the src port of the UDP response is 13221, while its looking for an UDP response with src port as 9800, for PORT Preservation and reforwarding back to 172.16.54.11:1456 (it's originating IP:PORT)
 
 Is there a way that the responses preserve the source port the (acting) server is listening on ?
 
 regards
 

Sanjay Upadhyay
Mobile +91-9231683108
AIM/Yahoo/Hotmail (Screen Name) - saneax
ICQ 76529342
SKYPE glowfriend
 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com