Strange TCP behaviour

Bruno De Graef schrieb:
 > Hi all,
 >
 > I'll start be describing our current situation. We have an apache
 > 1.3.19 ( old version, I know it but we need it due to compatibility
 > reasons with the application, an new version is in the pipe. ) running
 > as a reverse proxy. The host OS is running Solaris 2.8 with multiple
 > virtual addresses defined for 1 interface. Clients ( from remote sites
 > ) are connecting through VPN towards this reverse proxy.
 >
 > However since 2 weeks clients are complaining from timeouts from time
 > to time in the browser, where they need to refresh there page. After
 > having sniffed the network - client / server / switch - ( because
 > nothing was showing up in log files ) we found the following strange
 > behaviour in the TCP session.
 >
 > 1. Client SYN => Server
 > 2. Server ACK => Client ????????
 > 3. Client RST => Server
 > 4. Client SYN => Server
 > 5. Server SYN ACK => Client
 > 6. Client ACK => Server
 > 7. Server ACK => Client

Can you give us access to short trace from this behaviour?

Mirko

--
<a style='text-decoration: underline;' href="http://uridium.net/net/guide2na" target="_blank">http://uridium.net/net/guide2na</a> - Guide to Network Analysis<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Strange TCP behaviour 

In article <5da200e3.0405270108.3f55f1db.RemoveThis@posting.google.com>,
degraefb.RemoveThis@hotmail.com says...
 > However since 2 weeks clients are complaining from timeouts from time
 > to time in the browser, where they need to refresh there page. After
 > having sniffed the network - client / server / switch - ( because
 > nothing was showing up in log files ) we found the following strange
 > behaviour in the TCP session.
 >
 > 1. Client SYN => Server
 > 2. Server ACK => Client ????????
 > 3. Client RST => Server
 > 4. Client SYN => Server
 > 5. Server SYN ACK => Client
 > 6. Client ACK => Server
 > 7. Server ACK => Client
 >
 > As you can see the tree-way handshake is disturbed by the server
 > sending and ACK to the client with a higher packet number on the
 > intial SYN request.
 >
 > We are completely lost on the issue. Even our Telecom guys can't
 > explain the behaviour. Therefore we would like some advise on how to
 > explain the behaviour.
 >
 > Please find here a description on our architecture :
 > < Server 1 > - <SWITCH> - <Loadbalancer > - <Firewall> - <VPN> - <NAT
 > Firewall> - <Switch> - <Client PC>

Are you using F5? If so, you may be running a version that does not
randomize the tcp port numbers. I.e. people are stepping all over each
other.


--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Strange TCP behaviour 

Bruno De Graef <degraefb RemoveThis @hotmail.com> wrote:
[...]
 > However since 2 weeks clients are complaining from timeouts from time
 > to time in the browser, where they need to refresh there page. After
 > having sniffed the network - client / server / switch - ( because
 > nothing was showing up in log files ) we found the following strange
 > behaviour in the TCP session.
 >
 > 1. Client SYN => Server
 > 2. Server ACK => Client ????????
[...]
 > As you can see the tree-way handshake is disturbed by the server
 > sending and ACK to the client with a higher packet number on the
 > intial SYN request.
 >
Is the difference between 2.'s ACK value and 1's SEQ value one
million (1000000)?

Do you have a Raptor firewall, and has someone enabled "Enable SYN Flood
Protection" option? If so turn it off and make it a rule never to turn it
back on.

See,
<a style='text-decoration: underline;' href="http://service1.symantec.com/SUPPORT/ent-gate.nsf/3fcd5fb2fcae709e88256bc1005cd7c9/40544a361e41bcc485256ce10078cefc?OpenDocument" target="_blank">http://service1.symantec.com/SUPPORT/ent-gate.nsf/3fcd5fb2fcae709e8825...1005cd7</a>


 > We are completely lost on the issue. Even our Telecom guys can't
 > explain the behaviour. Therefore we would like some advise on how to
 > explain the behaviour.
 >
 > Please find here a description on our architecture :
 > < Server 1 > - <SWITCH> - <Loadbalancer > - <Firewall> - <VPN> - <NAT
 > Firewall> - <Switch> - <Client PC>
--
Alan J. McFarlane
<a style='text-decoration: underline;' href="http://homepage.ntlworld.com/alanjmcf/" target="_blank">http://homepage.ntlworld.com/alanjmcf/</a>
Please follow-up in the newsgroup for the benefit of all.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Strange TCP behaviour 

Hi,

"Bruno De Graef" <degraefb.TakeThisOut@hotmail.com> wrote in message
news:5da200e3.0405270108.3f55f1db@posting.google.com...
 > Hi all,
 >
 > I'll start be describing our current situation. We have an apache
 > 1.3.19 ( old version, I know it but we need it due to compatibility
 > reasons with the application, an new version is in the pipe. ) running
 > as a reverse proxy. The host OS is running Solaris 2.8 with multiple
 > virtual addresses defined for 1 interface. Clients ( from remote sites
 > ) are connecting through VPN towards this reverse proxy.
 >
 > However since 2 weeks clients are complaining from timeouts from time
 > to time in the browser, where they need to refresh there page. After
 > having sniffed the network - client / server / switch - ( because
 > nothing was showing up in log files ) we found the following strange
 > behaviour in the TCP session.
 >

I tried to understand this behaviour, but am not sure if details
provided are correct. Based on following :

 > 1. Client SYN => Server
 > 2. Server ACK => Client ????????
 > 3. Client RST => Server
 > 4. Client SYN => Server
 > 5. Server SYN ACK => Client
 > 6. Client ACK => Server
 > 7. Server ACK => Client
 >

a] Client had send the SYN to Server ( statement 1 ), Server replies
back with ACK only ??
- I believe this should have been SYN/ACK, and if not, then is it
a packet to some earlier connection.

b] Client sends reset to this ACK, why should it send a reset, may
be because,
- it was expectnig a SYN/ACK
- or there is something wrong in the ACK packet, possibly the target
port number, wrong ACK etc.

c] Statement 7, What did server ACK here.

I have assumed that the 7 statement, above are in sequence of what
is happening,


 > As you can see the tree-way handshake is disturbed by the server
 > sending and ACK to the client with a higher packet number on the
 > intial SYN request.

 >
 > We are completely lost on the issue. Even our Telecom guys can't
 > explain the behaviour. Therefore we would like some advise on how to
 > explain the behaviour.
 >
 > Please find here a description on our architecture :
 > < Server 1 > - <SWITCH> - <Loadbalancer > - <Firewall> - <VPN> - <NAT
 > Firewall> - <Switch> - <Client PC>

-One more thing, Loadbalancer is here, is "web acceleration" configured on
it,
what type of load balancing it is doing, is it layer 4 or layer 7. or simply
giving away the connection request to the servers in round robin fashion.

If the packet captures from 3 locations can be provided, I think it would be
very easy to find the culprit.
1] At server
2] At load balancer, Firewall end.
3] At Client.

It is highly probable that, there is something in Loadbalancer
configuration.

Regards
-Aashish Manocha<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Strange TCP behaviour