Sockets, Ports & NAT in C# -- [shaniqua:hover]

[Shaniqua Jones]

I've designed a C# application consisting of two EXEs: a client and
server. The server runs on my Win2000 Server box, and the client runs on my
customers' machines -- typically XP. The client app connects to the server,
makes a request, and awaits a response. The server sends back the response
at which point the client disconnects. The connection takes place on port
20198 (TCP). My server app was coded in such a way that only 10 simultaneous
connections are allowed from any client IP address. I did this to prevent
certain types of DOS attacks. Everything is working well -- except for one
customer.

This customer is saying that he is unable to connect to my server. The
server is rejecting his connection because his IP address has already
established 10 connections with my server. Sure enough, if I do a
"netstat -n" on my server, I see 10 connections from his IP. What makes this
interesting is that this customer does NOT have 10 connections open to my
server. I did a 'netstat' on *his* computer, the only machine in his office,
and NO such connections appeared. Even after physically turning his machine
OFF, these connections refuse to die. I can still see them via 'netstat' on
my server.

The only ways to get rid of these connections is to do ONE of the
following:

1) restart server.exe on my server.
2) reboot the customer's firewall.

Clearly, what is happening is that when my customer's client application
closes the connection, his LOCAL computer closes the connection, but his
firewall does not. It keeps it open indefinitely. I've never encountered
such bizarre behavior from a firewall.

Since the problem started yesterday, I asked my customer's I.T. person
if he made any changes to the firewall that day. He said that he HAD made a
change to his GnatBox firewall -- the change being that he added a VPN
tunnel to another branch office. However, I don't see how such a change
would be causing the odd behavior being exhibited by his firewall.

This problem only occurs with this one particular app that uses port
20198. Another almost identical app which uses port 8721 does NOT exhibit
the problem. Is there anything special about port 20198 that I should know?
When designing the app, I just chose 20198 at random. I've read that it's
best to use high-numbered ports for custom apps so as not to conflict with
the lower-numbered "well known" ports.

Any suggestions?

Shaniqua Jones

[Roland Hall]

"Shaniqua Jones" wrote in message
news:ut*************@TK2MSFTNGP10.phx.gbl...
: I've designed a C# application consisting of two EXEs: a client and
: server. The server runs on my Win2000 Server box, and the client runs on
my
: customers' machines -- typically XP. The client app connects to the
server,
: makes a request, and awaits a response. The server sends back the response
: at which point the client disconnects. The connection takes place on port
: 20198 (TCP). My server app was coded in such a way that only 10
simultaneous
: connections are allowed from any client IP address. I did this to prevent
: certain types of DOS attacks. Everything is working well -- except for one
: customer.
:
: This customer is saying that he is unable to connect to my server. The
: server is rejecting his connection because his IP address has already
: established 10 connections with my server. Sure enough, if I do a
: "netstat -n" on my server, I see 10 connections from his IP. What makes
this
: interesting is that this customer does NOT have 10 connections open to my
: server. I did a 'netstat' on *his* computer, the only machine in his
office,
: and NO such connections appeared. Even after physically turning his
machine
: OFF, these connections refuse to die. I can still see them via 'netstat'
on
: my server.
:
: The only ways to get rid of these connections is to do ONE of the
: following:
:
: 1) restart server.exe on my server.
: 2) reboot the customer's firewall.
:
: Clearly, what is happening is that when my customer's client
application
: closes the connection, his LOCAL computer closes the connection, but his
: firewall does not. It keeps it open indefinitely. I've never encountered
: such bizarre behavior from a firewall.
:
: Since the problem started yesterday, I asked my customer's I.T. person
: if he made any changes to the firewall that day. He said that he HAD made
a
: change to his GnatBox firewall -- the change being that he added a VPN
: tunnel to another branch office. However, I don't see how such a change
: would be causing the odd behavior being exhibited by his firewall.
:
: This problem only occurs with this one particular app that uses port
: 20198. Another almost identical app which uses port 8721 does NOT exhibit
: the problem. Is there anything special about port 20198 that I should
know?
: When designing the app, I just chose 20198 at random. I've read that it's
: best to use high-numbered ports for custom apps so as not to conflict with
: the lower-numbered "well known" ports.

Are you telling the client to close the connections or just hoping they will
on their own? It sounds like the proxy is keeping it open. Your app should
not depend on the remote hardware to determine when the connection should be
closed but rather notify it to terminate the connections from the server.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/service...p?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default...b;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default...b;EN-US;291382

[Shaniqua Jones]

> Are you telling the client to close the connections or just hoping they
will

on their own? It sounds like the proxy is keeping it open. Your app should not depend on the remote hardware to determine when the connection should be closed but rather notify it to terminate the connections from the server.

The client app automatically closes the connection after the information
is received. No problem there.

There are many ways around this problem -- for example, I could have the
server automatically close a connection if it's been idle for too long.
Although I'm not at a loss for solutions, I'm curious as to why this symptom
would be happening at all. I'm wondering if it has something to do with the
port that I chose.

[Roland Hall]

"Shaniqua Jones" <ki*******@Neverland.com> wrote in message
news:Oa**************@TK2MSFTNGP11.phx.gbl...
: > Are you telling the client to close the connections or just hoping they
: will
: > on their own? It sounds like the proxy is keeping it open. Your app
: should
: > not depend on the remote hardware to determine when the connection
should
: be
: > closed but rather notify it to terminate the connections from the
server.
:
: The client app automatically closes the connection after the
information
: is received. No problem there.

Perhaps the client should notify the server it's done so the server can
close the connection on it's end although having a timeout might still be
needed.

: There are many ways around this problem -- for example, I could have
the
: server automatically close a connection if it's been idle for too long.
: Although I'm not at a loss for solutions, I'm curious as to why this
symptom
: would be happening at all. I'm wondering if it has something to do with
the
: port that I chose.

I doubt it's the port you chose. I'm not aware of them being unique in that
respect. You can test with another port but if it was the port, wouldn't
all of them being having issues instead of just one user? Is it possible
the user can run the client from a different location that doesn't use this
device to test it? I cannot tell you why it appears to cache the
connections. I think what you might find is if this one does it, and it is
the firewall, then you might run into other devices that do the same thing
and even if you could make a modification in the firewall, this problem may
resurface.

[Shaniqua Jones]

> Perhaps the client should notify the server it's done so the server can

close the connection on it's end although having a timeout might still be
needed.
That's probably the direction I'm going to go.
I doubt it's the port you chose. I'm not aware of them being unique in that respect. You can test with another port but if it was the port, wouldn't
all of them being having issues instead of just one user?

Precisely. My thoughts exactly... That's why this is so frustrating....
:(

It bugs me that I'll probably never discover the real reason for this
error. One other thing of note. I discovered that the problem started
immediately after my customer upgraded the firmware on his GnatBox firewall.

[Roland Hall]

"Shaniqua Jones" <ki*******@Neverland.com> wrote in message
news:Oa**************@TK2MSFTNGP11.phx.gbl...
: > Are you telling the client to close the connections or just hoping they
: will
: > on their own? It sounds like the proxy is keeping it open. Your app
: should
: > not depend on the remote hardware to determine when the connection
should
: be
: > closed but rather notify it to terminate the connections from the
server.
:
: The client app automatically closes the connection after the
information
: is received. No problem there.

Perhaps the client should notify the server it's done so the server can
close the connection on it's end although having a timeout might still be
needed.

: There are many ways around this problem -- for example, I could have
the
: server automatically close a connection if it's been idle for too long.
: Although I'm not at a loss for solutions, I'm curious as to why this
symptom
: would be happening at all. I'm wondering if it has something to do with
the
: port that I chose.

I doubt it's the port you chose. I'm not aware of them being unique in that
respect. You can test with another port but if it was the port, wouldn't
all of them being having issues instead of just one user? Is it possible
the user can run the client from a different location that doesn't use this
device to test it? I cannot tell you why it appears to cache the
connections. I think what you might find is if this one does it, and it is
the firewall, then you might run into other devices that do the same thing
and even if you could make a modification in the firewall, this problem may
resurface.

[Shaniqua Jones]

> Perhaps the client should notify the server it's done so the server can

close the connection on it's end although having a timeout might still be
needed.
That's probably the direction I'm going to go.
I doubt it's the port you chose. I'm not aware of them being unique in that respect. You can test with another port but if it was the port, wouldn't
all of them being having issues instead of just one user?

Precisely. My thoughts exactly... That's why this is so frustrating....
:(

It bugs me that I'll probably never discover the real reason for this
error. One other thing of note. I discovered that the problem started
immediately after my customer upgraded the firmware on his GnatBox firewall.

[Roland Hall]

"Shaniqua Jones" <ki*******@Neverland.com> wrote in message
news:uC****************@TK2MSFTNGP12.phx.gbl...
: > Perhaps the client should notify the server it's done so the server can
: > close the connection on it's end although having a timeout might still
be
: > needed.
:
: That's probably the direction I'm going to go.
:
: > I doubt it's the port you chose. I'm not aware of them being unique in
: that
: > respect. You can test with another port but if it was the port,
wouldn't
: > all of them being having issues instead of just one user?
:
: Precisely. My thoughts exactly... That's why this is so
frustrating....
: :(
:
: It bugs me that I'll probably never discover the real reason for this
: error. One other thing of note. I discovered that the problem started
: immediately after my customer upgraded the firmware on his GnatBox
firewall.

I went to gta.com, I think it was, and looked at some of the docs but not
knowing which router might have been the reason I really didn't see anything
related. I didn't sign up for their discussion forums but that might be an
avenue to explore. It seems I remember someone asking about something
similar with a proxy server caching connections but I believe it was related
to issues regarding the true IP address.

How does the server close the connection now?

[Roland Hall]

"Shaniqua Jones" <ki*******@Neverland.com> wrote in message
news:uC****************@TK2MSFTNGP12.phx.gbl...
: > Perhaps the client should notify the server it's done so the server can
: > close the connection on it's end although having a timeout might still
be
: > needed.
:
: That's probably the direction I'm going to go.
:
: > I doubt it's the port you chose. I'm not aware of them being unique in
: that
: > respect. You can test with another port but if it was the port,
wouldn't
: > all of them being having issues instead of just one user?
:
: Precisely. My thoughts exactly... That's why this is so
frustrating....
: :(
:
: It bugs me that I'll probably never discover the real reason for this
: error. One other thing of note. I discovered that the problem started
: immediately after my customer upgraded the firmware on his GnatBox
firewall.

I went to gta.com, I think it was, and looked at some of the docs but not
knowing which router might have been the reason I really didn't see anything
related. I didn't sign up for their discussion forums but that might be an
avenue to explore. It seems I remember someone asking about something
similar with a proxy server caching connections but I believe it was related
to issues regarding the true IP address.

How does the server close the connection now?

[Shaniqua Jones]

> How does the server close the connection now?

My customer has a support incident open with the firewall manufacturer.
We'll see if anything comes of it.

The client initiates a connection to the server. Once the connection is
established, the client sends a request. The server does some processing and
sends back a response. Once the client receives the response and processes
it, it then closes the connection. The server then detects that the
connection has ended [Socket.EndReceive() returns zero or throws] and then
calls Socket.Close() [which might be somewhat redundant since the connection
is already closed].

I've been using this technique for years and it works for many other
applications and users. It only fails for this one user and only on that
particular port. The same customer using my other apps (that use other
ports) do not have this problem.Weird!

After the client disconnects, running 'netstat' on his machine shows
that the connection is gone. Good.... but when looking at the active
connections on his firewall, the connection is still alive and refuses to
die. Two times out of five, the firewall will release the connection
correctly immediately. The other three times, it'll fail.

David

[Roland Hall]

"Shaniqua Jones" <ki*******@Neverland.com> wrote in message
news:ev**************@TK2MSFTNGP10.phx.gbl...
: > How does the server close the connection now?
: >
:
: My customer has a support incident open with the firewall
manufacturer.
: We'll see if anything comes of it.
:
: The client initiates a connection to the server. Once the connection
is
: established, the client sends a request. The server does some processing
and
: sends back a response. Once the client receives the response and processes
: it, it then closes the connection. The server then detects that the
: connection has ended [Socket.EndReceive() returns zero or throws] and then
: calls Socket.Close() [which might be somewhat redundant since the
connection
: is already closed].
:
: I've been using this technique for years and it works for many other
: applications and users. It only fails for this one user and only on that
: particular port. The same customer using my other apps (that use other
: ports) do not have this problem.Weird!
:
: After the client disconnects, running 'netstat' on his machine shows
: that the connection is gone. Good.... but when looking at the active
: connections on his firewall, the connection is still alive and refuses to
: die. Two times out of five, the firewall will release the connection
: correctly immediately. The other three times, it'll fail.

Is it possible you could have the client notify the server to close the
connection rather than having the server detect the loss only? I would
still use the detection in case of an unexpected disconnect but telling the
server to close would have many benefits beyond this issue.

I wonder if the firewall has a keep-alive setting but then one would wonder
why this doesn't happen with different ports. Hopefully the manufacturer
can give you some insight on the anomaly.

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/service...p?fr=0&sd=tech
How-to: Windows 2000 DNS:
http://support.microsoft.com/default...b;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default...b;EN-US;291382