ASA 5510 8.2(5) Conn/Xlate

[Rafael Mendes]

Hello,

I Have a problem here.

Some times the connection from one ip "out of the firewall" to an ip behind a firewall stops, when it occurs, i send the commands "clear conn origin ip address" and clear xlate "origin ip address", after that, the communication returns.

ACL:

access-list acl_inside extended permit tcp host 172.17.2.116 host SPB-SGR-Producao eq 1414

Conn:

TCP dmz SPB-SGR-Producao:1414 inside 172.17.2.116:24811, idle 0:00:15, bytes 0, flags saA

TCP dmz SPB-SGR-Producao:1414 inside 172.17.2.116:24756, idle 0:05:55, bytes 1056, flags UO

Help?

Tks!

[Jouni Forss]

Hi,

If I am not mistaken the first connections shown in the above output is a connection which the LAN host has tried to open. However the ASA has not seen any reply to the TCP connection forming so that connections is probably about to be teardown with the reason SYN Timeout.

The other seems to be a TCP connection that has fully formed. However there only seems to be outbound traffic and no data transmitted inbound.

- Jouni

[Rafael Mendes]

Hi Jouni,

But it connection was working before, some times the firewall "lock" the connection, and unlock only after i do clear conn and clear xlate commands.

It can be a bug?

[Rafael Mendes]

The problem occurs with various origin ip address, host 172.17.2.116 it only a example.

[Andrew Phirsov]

I think the issue may be somehow related to the application that runs on tcp/1414 in your case, and when you resetting the connection by using clear  conn, app just initiates it again and works for some time, until error  or whatewer it is (on application level) happens again.

[Rafael Mendes]

Hi Andrew,

I think the issue is a problem in the firewall, it application runs here for five years, and this problem occurs only a few months ago.

[Andrew Phirsov]

Then, if the problem occurs frequently enough, try to run capture on ASA for traffic between some client and the server, so u'll be able to see, why the connection stops working.

[Jouni Forss]

Hi,

The only real way to tell what is happening is taking captures on the internal and external firewall interface.

You could then compare them with eachother and also look at the capture from the time that this problem occurs.

Only way I imagine the clear conn/xlate might affect this situation is that the host has the connection to the remote host and when you clear the connection and xlate the host will send more data to the existing connection (which the ASA doesnt have anymore) and the ASA in that case might probably send a TCP Reset to the host. At this point the host will probably form a new connection that corrects the situation.

Otherwise I dont think the ASA has any affect on the actual host reinitiating the connection since the only situation where the ASA should send anything to the actual client in the internal network should be when it sees a outboud connection that is not allowed. Then the ASA should send a TCP Reset to my understanding.

But as you showed above the 2 connections in the ASAs connection table, the other one is clearly a connection from the Internal network towards the remote host in which the host has sent the TCP SYN but has not received anything back from the remote host. This would again point to a problem at the remote side.

But without doing the captures and seeing/monitoring logs we can only guess what the actual cause of the problem is.

- Jouni

[Jouni Forss]

Hi,

Just to give you an example of the capture configuration format

access-list INSIDE-CAP permit ip host host

access-list INSIDE-CAP permit ip host host

capture INSIDE-CAP type raw-data access-list INSIDE-CAP interface inside buffer 33500000 circular-buffer

access-list DMZ-CAP permit ip host host

access-list DMZ-CAP permit ip host host

capture DMZ-CAP type raw-data access-list DMZ-CAP interface dmz buffer 33500000 circular-buffer

Then you could use the following command to confirm that traffic is getting captured

show capture

You could use the following command to show the capture contents on the CLI (I prefer to download the capture contents to a host)

show capture INSIDE-CAP

show capture DMZ-CAP

You can copy the capture as a .pcap file to a local host and open it with Wireshark to make the analyzing easier

copy /pcap capture:INSIDE-CAP tftp://x.x.x.x/INSIDE-CAP.pcap

copy /pcap capture:DMZ-CAP tftp://x.x.x.x/DMZ-CAP.pcap

And you can remove the captures with the following commands when you dont have any more use for them. (ACLs will have to be removed separately)

no capture INSIDE-CAP

no capture DMZ-CAP

- Jouni

[Rafael Mendes]

Tks.

When the problem occurs again, i will capture the traffic.

Tks!