NAT and keepaliveopen connection over TCP

Hi,

I have a TCP server that listening to tcp clients, this server can accept incoming tcp requests.

Some of the clients are behind NAT.

The client makes connection, and then I set keepalive on both sides (server & client)

in some Nat's it's work fine , and in others the client suddenly after work correctly send the packets with other port (external - Nat port) to the server , even if I use the same already opened socket !

For ex.

Client A (192.168.1.1) is behind NAT B (60.78.95.144) make connection to Server S (87.170.65.132) on that listening on port 1000.

The NAT will change the port number from 1000 to 2000

The connection established.

Then

When the connection is still established the client try to send let say 30 bytes to the server

In the server we have connection to 60.78.95.144:2000 and we try to read from it.

But the packet from the NAT will come from 60.78.95.144:3000



What cause it?

There is some specific Nat that make it?

How can I identify that Nat will act like this (in the program c#)

How to correct it?

Maybe I should avoid the keepalive and use my "keep alive" by sending packets to the server every X interval? (And if yes, how to know what is the interval)

Or maybe the server should send to the client?

Thanks


Relevant Pages

  • Re: FTP Server setup... Im so close!
    ... > I have installed the Internet Information Services, etc, and have the FTP ... Your external client is trying to use Passive Mode. ... Since your server is behind NAT, ...
    (microsoft.public.windowsxp.network_web)
  • Re: Netzwerkproblem GBit -> 100MBit
    ... GBit-Kette - flow control zwingend notwendig sei. ... zwischen Client und Server. ... Das kann TCP an der Stelle nicht mehr leisten. ...
    (de.comp.sys.novell)
  • suspect bug in vge(4)
    ... The high-level view of the problem is that the client seems to stall ... HTTPS server. ... not only printed for TLS/SSL issues but simply also for broken TCP ... To me it sounds like a broken implementation of hardware generated ...
    (freebsd-current)
  • Re: Log Out Issues
    ... UDP is the way to go for internet games. ... Apparently the extra overhead in TCP can cause a lot more lag in your game, ... >> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Log Out Issues
    ... your perormance may be worse than TCP. ... would be if your protocol anticipates packet loss and does not ... >>> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)