ASA - Deny TCP (no connection)

tech_trac · ‎08-11-2009

Hello,

Scratching my head with this problem.

Email notifications are not getting generated from the inside network.

Quick Topology:

Inside -> FWSM -> 6500 (NAT) -> 2nd Level ASA -> 1st Level ASA (PAT)

The SMTP access is allowed throughout. I can see Build/Teardown on FWSM and 2nd Level ASA. However, on 1st Level ASA I can see 'Deny TCP (no connection)..RST Flag' in the logs of 1st Level ASA for the return traffic.

Going through forums etc, I believe there are mainly two reasons for this error 1) Asymmetric routing 2) SMTP inspection

In my case, neither Asymmetric routing nor SMTP inspection is occuring. Still I get the above error.

Please assist.

Thanks.

tech_trac · ‎08-12-2009

Please assist.

Thanks.

Kevin Redmon · ‎08-13-2009

Deny TCP (no connection) is a statement that a packet arrived on the firewall for a connection that doesn't exist - the connection may never existed or recently torn down. To determine what may have caused this situation, choose a single connection (source/destination IP address) and configure a packet capture on the ingress and egress interfaces as described at this link (be sure to use the interface specific/NAT IP addresses):

http://www.nortfm.com/?View=entry&EntryID=1

Also, to supplement this packet capture, enable the following:

logging buffered debugging

logging timestamp

logging buffer-size 512000

Run an example test (matching the configured packet capture) and gather all relevant logs from the time of the traffic. This syslog output as well as the packet captures should provide you an insight as to what the issue is.

If SMTP inspection is enabled, you may want to confirm whether the SMTP server sends a TCP Reset. Also, confirm if any SMTP commands as sent between the client and server are modified to X's. Sometimes, changing the available SMTP commands can result in a reset from the SMTP Server with a 500 ERROR. More information about 'inspect esmtp' is available at the link below:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i2.html#wp1719425

This 'RST Flag' Deny TCP (no connection) may be just a final errant packet sent from the host after the connection was torn down by the ASA or the other end. A packet capture and syslogs of the flow will greatly assist diagnosing the issue.

Hope this helps.

tech_trac · ‎08-16-2009

Hello,

It is a Production ASA. Would logging buffered debugging degrade the performance at all.

Thanks.

Kevin Redmon · ‎08-16-2009

'logging buffered debugging' rarely degrades performance on a production box in my experience. However, do NOT enable 'logging traps debugging' or 'logging console debugging' if your ASA is heavily utilized. This could impact performance.

tech_trac · ‎10-11-2009

Hello,

I have pasted below the capture and debug log from ASA. I can see that mail server initiated a 'sackOK' after the beginning TCP handshake to which ASA responded with RST. What is 'sackOK' used for.

INTERNET SMTP Mail Server = 66.87.124.55

SMTP Sender Sender = 172.16.30.160 (NAT'ed IP)

ASA Outside Interface = 88.23.43.98

Capture:

19: 17:20:26.624982 172.16.30.160.1231 > 66.87.124.55.25: S

1157537987:1157537987(0) win 65535

20: 17:20:26.625166 88.23.43.98.54446 > 66.87.124.55.25: S

1916008998:1916008998(0) win 65535

21: 17:20:26.868882 66.87.124.55.25 > 88.23.43.98.54446: S

2012653347:2012653347(0) ack 1916008999 win 5840

22: 17:20:26.868912 66.87.124.55.25 > 172.16.30.160.1231: S

3195801731:3195801731(0) ack 1157537988 win 5840

23: 17:20:26.869660 172.16.30.160.1231 > 66.87.124.55.25: . ack

3195801732 win 65535

24: 17:20:26.869690 88.23.43.98.54446 > 66.87.124.55.25: . ack

2012653348 win 65535

25: 17:20:27.116311 66.87.124.55.59671 > 88.23.43.98.113: S

2007441486:2007441486(0) win 5840

26: 17:20:27.116372 88.23.43.98.113 > 66.87.124.55.59671: R 0:0(0) ack

2007441487 win 5840

27: 17:20:27.363155 66.87.124.55.25 > 88.23.43.98.54446: P

2012653348:2012653456(108) ack 1916008999 win 5840

28: 17:20:27.363170 66.87.124.55.25 > 172.16.30.160.1231: P

3195801732:3195801840(108) ack 1157537988 win 5840

29: 17:20:27.363491 66.87.124.55.25 > 88.23.43.98.54446: F

2012653456:2012653456(0) ack 1916008999 win 5840

30: 17:20:27.363506 66.87.124.55.25 > 172.16.30.160.1231: F

3195801840:3195801840(0) ack 1157537988 win 5840

31: 17:20:27.363888 172.16.30.160.1231 > 66.87.124.55.25: . ack

3195801841 win 65427

32: 17:20:27.363903 88.23.43.98.54446 > 66.87.124.55.25: . ack

2012653457 win 65427

33: 17:20:27.364620 172.16.30.160.1231 > 66.87.124.55.25: P

1157537988:1157538010(22) ack 3195801841 win 65427

34: 17:20:27.364650 88.23.43.98.54446 > 66.87.124.55.25: P

1916008999:1916009021(22) ack 2012653457 win 65427

35: 17:20:27.373744 172.16.30.160.1231 > 66.87.124.55.25: FP

1157538010:1157538082(72) ack 3195801841 win 65427

36: 17:20:27.373759 88.23.43.98.54446 > 66.87.124.55.25: FP

1916009021:1916009093(72) ack 2012653457 win 65427

Debug Log:

Oct 2 2009 17:19:30: %ASA-6-302013: Built outbound TCP connection

242317791 for OUTSIDE-INTERFACE:66.87.124.55/25 (66.87.124.55/25) to

INSIDE-INTERFACE:172.16.30.160/1151 (88.23.43.98/54445)

Oct 2 2009 17:19:31: %ASA-6-302014: Teardown TCP connection 242317791 for

OUTSIDE-INTERFACE:66.87.124.55/25 to INSIDE-INTERFACE:172.16.30.160/1151

duration 0:00:00 bytes 130 TCP FINs

Oct 2 2009 17:20:26: %ASA-6-302013: Built outbound TCP connection

242319817 for OUTSIDE-INTERFACE:66.87.124.55/25 (66.87.124.55/25) to

INSIDE-INTERFACE:172.16.30.160/1231 (88.23.43.98/54446)

Oct 2 2009 17:20:27: %ASA-6-302014: Teardown TCP connection 242319817 for

OUTSIDE-INTERFACE:66.87.124.55/25 to INSIDE-INTERFACE:172.16.30.160/1231

duration 0:00:00 bytes 202 TCP FINs

Oct 2 2009 17:20:27: %ASA-6-106015: Deny TCP (no connection) from

66.87.124.55/25 to 88.23.43.98/54446 flags RST on interface

OUTSIDE-INTERFACE

Thanks.

Kureli Sankar · ‎10-11-2009

It gets extremely complicated to troubleshoot any one flow when you have multiple firewalls in the path.

With that said, these deny tcp no conn syslog is only for a reset packet, which is ok to see. Once the conn gets torn down, reset packets for the same flow arrives which does not get passed on to the other interface for the reason no connection in the table.

Pls. see if you can eliminate one firewall at a time by placing the client after one firewall at a time.