asa deny tcp (no connection)

Answered Question
Mar 26th, 2010
User Badges:

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!

Correct Answer by Jennifer Halim about 7 years 1 month ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
fosterl2 Fri, 03/26/2010 - 13:13
User Badges:

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

Correct Answer
Jennifer Halim Fri, 03/26/2010 - 20:36
User Badges:
  • Cisco Employee,

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 Wed, 03/31/2010 - 02:41
User Badges:

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 Wed, 12/01/2010 - 16:06
User Badges:

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 Wed, 12/01/2010 - 16:26
User Badges:
  • Cisco Employee,

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

Rodrigo Gurriti Wed, 12/01/2010 - 16:44
User Badges:

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 Wed, 12/01/2010 - 17:18
User Badges:
  • Cisco Employee,

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 Wed, 12/01/2010 - 18:10
User Badges:

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 Wed, 12/01/2010 - 18:16
User Badges:
  • Cisco Employee,

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.

Actions

This Discussion