'sh conn' tcp state - connection problem.

[labj]

Hi,

I'm seeing random connection problems from hosts running through the inside of my PIX535 (6.1.1) through a global IP, to a couple of specific webservers on the internet.

When the problem accurs, machines PAT'ted behind the global have full IP connectivity to the mentioned web-servers, but not tcp/80

Staticly NAT'ted machines are not affected by the problem.

I can see (with 'sh conn for [webserver-ip]' and 'sh xlate') that the workstations are PAT'ted correctly to a global port, and that a connection-attempt is made:

y.y.y.y = workstation IP

x.x.x.x = my global IP

z.z.z.z = the foreign webserver

f-edb1-1# sh xlate local [y.y.y.y]

PAT Global [x.x.x.x](16412) Local y.y.y.y(1959)

f-edb1-1#sh conn foreign z.z.z.z

TCP out z.z.z.z:80 in y.y.y.y:1959 idle 0:00:45 Bytes 0 flags saA

What I'm not sure of, is what the flags 'saA' exactly means? I found following on cisco.com:

s - awaiting outside SYN

a - awaiting outside ACK to SYN

A - awaiting inside ACK to SYN

the two aA's are logical to me: the firewall hasn't recieved an ACK packet from the webserver yet.

However, I'm not shure on what to conclude on the "s". What does "awaiting outside SYN" actually mean? Have my firewall forwarded the workstations SYN-packet at this point?

Thanks in advance,

--

Lasse Bjorn Jensen

[nkhawaja]

Hi,

So every TCP connection contains 2 SYN and 2 ACK. What I believe "s" is the SYN from the outside server.

Now to your main problem. Here is a link that talks about IDENT. What seems to be your case.

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_tech_note09186a0080094317.shtml

Thanks

Nadeem

[labj]

Thanks for your reply.

However I don't quite understand what you mean by:

> What I believe "s" is the SYN from the outside server

Shouldn't I just expect a ACK from the webserver, as an answer to my workstations SYN?

So what state is my connection exactly in, when my firewall says 'flags: saA'?

I am already aware that IDENT can cause such a problem, but I don't think this is the case here; the problem is random ie. does not always occur, but when it occurs, it's always with a small range of known webservers.

[scoclayton · Accepted solution]

Standard TCP protocol requires that the receiver respond to an initial SYN packet with a SYN ACK. The flags saA indicate that we saw a SYN from an inside client and are awaiting the SYN ACK (sa) from the outside host and then the ACK (A) from the inside host in response to the SYN ACK. Looks like the target machine is not responding to the clients using the PAT address. We would need more information to determine the cause. Hope this helps.

Scott

[labj]

Hi Scott,

Thanks for your answer.

My initial feeling was also, that the problem was in the 'other end', but I wanted to be ashured that I had understood exactly where in the tcp handshake process the connection had stopped before I talked to the target hosts' administrators.