Discussion:
Client/Server socket through a NAT?
(too old to reply)
Grant Schenck
2009-10-20 17:07:14 UTC
Permalink
Hello,

I have a strange issue with a client server application I developed in C#
.NET. This doesn't actually use remoting, rather it uses sockets but I
don't see a news group that specific. If this would be better posted in
different news group then please let me know...

The problem we have is that our server is on one subnet and our clients are
on another subnet. I track the connected clients by IP address. The
problem I have is that all clients come in with the IP address of the
gateway where the NAT is running. The result is that one client can connect
but when a second client connects I see the same IP address and assume that
somehow the previous connection was not torn down and disconnect the
previous connection. The result is that only one client can connect at a
time.

This is an area I know virtually nothing about but I thought the whole point
of a NAT is to virtualize connections in such a way that applications just
work. I shouldn't have to code specially to work with clients connected via
NAT, should I?

I'm thinking this is an issue with the configuration of their NAT but I
don't know. My other concern is that somehow this is just a limitation of
client/server software where the client and server connect via a NAT and
while I assume most companies run NATs, they probably run those between the
public internet and their network, not between subnets of their network.

Any and all advice would be very much appreciated!

Thanks in advance.
--
Grant Schenck
Chris Taylor
2009-11-01 11:41:25 UTC
Permalink
Hi,

Using the source IP address would be unreliable even if it was "exposed"
through NAT. Imagine that you have two independent networks both using the
same private IP range, it is feasible for a machine on one of the networks
to have the same IP as a machine on the other network.

If I have understood your requirement correctly, you want a client from a
specific machine to pick up the same session even if the initial connection
is lost and the client re-establishes the connection. To handle this you
should use a application level protocol, based on some piece of unique
information that the connecting client passes to you on the initial
connection. I hesitate to give a concrete example, because I do not want you
to confuse the example with your actual system design and requirements, but
I hope this explanation is clear enough for you to extrapolate an
appropriate solution in your environment.

Hope this helps
--
Chris Taylor
http://taylorza.blogspot.com
http://twitter.com/taylorza
Post by Grant Schenck
Hello,
I have a strange issue with a client server application I developed in C#
.NET. This doesn't actually use remoting, rather it uses sockets but I
don't see a news group that specific. If this would be better posted in
different news group then please let me know...
The problem we have is that our server is on one subnet and our clients
are on another subnet. I track the connected clients by IP address. The
problem I have is that all clients come in with the IP address of the
gateway where the NAT is running. The result is that one client can
connect but when a second client connects I see the same IP address and
assume that somehow the previous connection was not torn down and
disconnect the previous connection. The result is that only one client
can connect at a time.
This is an area I know virtually nothing about but I thought the whole
point of a NAT is to virtualize connections in such a way that
applications just work. I shouldn't have to code specially to work with
clients connected via NAT, should I?
I'm thinking this is an issue with the configuration of their NAT but I
don't know. My other concern is that somehow this is just a limitation of
client/server software where the client and server connect via a NAT and
while I assume most companies run NATs, they probably run those between
the public internet and their network, not between subnets of their
network.
Any and all advice would be very much appreciated!
Thanks in advance.
--
Grant Schenck
Loading...