Ronnie Sahlberg wrote:
ftp://ftp.rfc-editor.org/in-notes/rfc3360.txt
That would indeed be a very odd, if not stupid thing to do, but some
firewalls and other devices work in this broken way.
Considering that S Floyd is much smarter than any one else implementing TCP,
someone that violates what
S Floyd says is essential clueless.
Coming into this debate a bit late I can offer these observations from
personal experience.
At one time we had a number of web servers behind a load balancer. On
the outside of the load balancer is a firewall. The firewall is
configured to disallow spoofing.
If the traffic is high enough the ephemeral port numbers in the http
traffic get reused within the spoofing timeout limit. The firewall
silently drops the packet. The web servers eventually almost go to sleep
due to running out of port numbers because too many connections are hung
in SYN-SENT.
Reconfigure the firewall to issue RST instead of silence and the
problems go away. Convicing security to do that? Almost impossible.
----- Original Message -----
From: "Ian Schorr"
Sent: Friday, August 06, 2004 2:21 AM
Subject: Re: [Ethereal-users] RST flag question
It's possible that some network device may be intercepting the
conversation and "killing" the connection, though this would be a bit
odd way for it to happen. Especially not in a well-designed network.
A traditional "router" has no concept of TCP connections and wouldn't
do anything here. A firewall, VPN device, etc might but typically
they'll simply "absorb" traffic they don't like (instead of explicity
generating a RST), and stateful firewalls will usually allow return
traffic on a conversation if it allowed the conversation to be
initiated in the first place (so it's odd, but definitely not
impossible, that the SYN-ACK would be RST)
If you take a trace at the client side, to do you see it explicitly
generating the RST? If so, there's no network equipment involved with
your problem here (at least not generating the RST, though if something
is making modifications to traffic your client may not like what's
happening)
If so, sounds to me like your app started to open a connection but
failed, aborted, or in some other way was no longer active on the
socket that it initiated the connection on when SYN-ACK returned. Is
latency between these two sites particularly high? Does your app have
some extremely small connection timeout? Either way I'd expect to see
some immediate and negative result code from whatever you're using to
open the connection.
Otherwise, if the client doesn't see the SYN-ACK returned to it, your
problem sounds like it's in network hardware somewhere. Do you have a
firewall in the way? VPN device? Firewall features enabled in the
Cisco firewall?
Ian
On Aug 5, 2004, at 11:48 AM, Matt Kopf wrote:
Although I agree with this. These are both computers that we control,
and
the handshake is started with the start of our own application. It
works
just fine over the LAN, but when you take the computer to this remote
location that goes over the Cisco router you see the RST flag and the
application dies. So I am very sure that it is not a SYN scan in this
particular situation at least. At least I know what to keep my eyes
open for
though Thanks!
Matt
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
