asa deny tcp (no connection)

[fosterl2]

I have an ASA that has been working fine, and possibly since a reboot is blocking TCP traffic.

It is returning "Deny TCP (no connection) from 172.19.139.144/80 to 147.167.24.232/1587 flags SYN ACK  on interface Outside", as it believes there is no stateful connection - see log - bottom to top:

147.167.24.232|1587|172.19.139.144|80|Teardown TCP connection 6408 for Outside:147.167.24.232/1587 to inside:172.19.139.144/80 duration 0:00:30 bytes 0 SYN Timeout (BT_test)

172.19.139.144|80|147.167.24.232|1587|Deny TCP (no connection) from 172.19.139.144/80 to 147.167.24.232/1587 flags SYN ACK  on interface Outside
172.19.139.144|80|147.167.24.232|1587|Deny TCP (no connection) from 172.19.139.144/80 to 147.167.24.232/1587 flags SYN ACK  on interface Outside
172.19.139.144|80|147.167.24.232|1587|Deny TCP (no connection) from 172.19.139.144/80 to 147.167.24.232/1587 flags SYN ACK  on interface Outside

147.167.24.232|1587|172.19.139.144|80|Built inbound TCP connection 6408 for Outside:147.167.24.232/1587 (147.167.24.232/1587) to inside:172.19.139.144/80 (172.19.139.144/80) (BT_test)

However, the top entry is where it is showing that the connection that it thinks does not exist, is clearing down...

It is dropping all TCP traffic, not just this flow, but a ping with the same addresses passes fine.

Any ideas greatly appreciated!

[fosterl2]

...by the way, I have OS version 8.0(4) running.

[Jennifer Halim · Accepted solution]

Seems like a routing loop to me.

From the logs, it seems that the connection is from Outside to Inside, ie:

Outside:147.167.24.232 --> inside:172.19.139.144

So for TCP 3 way handshake, it should be as follows:

SYN: Outside --> Inside

SYN-ACK: Inside --> Outside

ACK: Outside --> Inside

From the logs, here is instead what happens:

SYN: Outside --> Inside

SYN-ACK: Outside --> Inside

Hence the ASA is dropping the connection. The SYN-ACK packet is actually received on the outside interface instead of the inside interface as it should be.

Hope that helps.

[fosterl2]

Well spotted!

I had missed the subtly of that, focusing on the fact that *something* was being received.

With the help of this info, I found that on the site, they had connected the LAN with the Internet (external) connection with a cable to the LAN on the inside.  As you would think, this gives unpredictable behavior at layer 2, and by purely good fortune it had been working until a reboot, where the re-ARPing resulted in the outside MAC address answering a request for the network address on the inside interface - hence how packets that should have returned to the inside interface appeared on the outside one instead.

[Rodrigo Gurriti]

Jennifer,

I'm sorry to hijack this topic but I have a similar situation:

VPN site to site

The ASA internal network 10.1.4.62 (this internal host is behind an MPLS network)

The remote network 201.44.112.113

Here I have an test, remote site trying to access the internal network

6    Nov 10 2010    09:30:44    106015    10.1.4.62    201.44.112.113     Deny TCP (no connection) from 10.1.4.62/401 to 201.44.112.113/25682 flags SYN ACK  on interface inside

VPN works, ping goes fine, but I have a problem with TCP

The difference here is that its really doing the 3 way handshake like this:

SYN: Outside --> Inside

SYN-ACK: Inside --> Outside

[Jennifer Halim]

Can you please check the routing that 10.1.4.62 is actually being routed off the inside interface?

[Rodrigo Gurriti]

Jennifer,

Here is some piece of information:

interface GigabitEthernet0/1

nameif outside

security-level 0

ip address (public-address)  255.255.255.240 standby (public-address)

!

interface GigabitEthernet0/2

nameif inside

security-level 100

ip address 10.1.1.5 255.255.252.0 standby 10.1.1.6

!

......

!

route outside 0.0.0.0 0.0.0.0 (public-address) 1
route inside 10.0.0.0 255.0.0.0 10.1.1.1 1

Its been routed to the inside interface.

(ASA only has 2 interfaces working, and that is all the routing)

10.1.1.1 1 -> internal core & gateway (has routes configured correctly, to every MPLS network it points to the MPLS router)

[Jennifer Halim]

Thanks.

In that case, you might want to check if the TCP connection itself has timeout because of the delay in getting the SYN-ACK packet.

By default, the TCP incomplete timeout is 30 seconds.

Here is how it goes:

- ASA receives SYN, and place that in the connection table.

- If the ASA does not receive the SYN-ACK packets within 30 seconds, it will clear that particular connection.

- So if the SYN-ACK packet arrives at the ASA after the default timeout of 30 seconds, you will receive that error message of no TCP connection found.

The embryonic connection timeout of 30 seconds is to ensure that there is no stale incomplete connections in the ASA connection table.

[Rodrigo Gurriti]

Thank you

I'll try double that time,is there any other way to do it or only using the police-map set-connection ?

Is there a way that the MPLS can alter the packet some how that when it gets back to the ASA it rejects. I see that the source and dest. are correct but i dont know about the TCP sequencing information

[Jennifer Halim]

The best thing to check is to run packet capture on the inside interface for both inbound and outbound connection between the 2 hosts.

That would tell you exactly what happen, and you can download the packet capture in pcap format and check it on wireshark/ethereal.

"police-map set-connection" is the only way to increase the embryonic timeout.

[Jake.Fritz]

Hi Rodrigo/All,

I know this thread has been updated a long time ago but I am facing similar issue and wanted to see what was done. Were you able to get it resolved? Was it an issue with route or access-list?

Thanks,
Jake