TCP Handshake fails on Cisco ASA

Question

I am using a Traffic Generator for setting up a TCP connection that should pass a Cisco ASA firewall.

My topology looks like this:

                     +------------------+                      
                     |  CISCO ASA       |                      
+------------+       |                  |                      
|  Client    +-------+Outside           |                      
|  10.1.202.1|       |10.1.202.254      |                      
|            |       |                  |        +------------+
+------------+       |            Inside|        |Server      |
                     |      10.1.102.254+--------+10.1.102.19 |
                     |                  |        |            |
                     +------------------+        +------------+

The connection should be established from one host in the external network (10.1.202.1/24) to a server in the internal network (10.1.102.19/24).

I see in Wireshark that the SYN passes the firewall (10.1.(1/2)02.254), the SYN-ACK does not pass and is dropped (see captures: inside-interface and the outside-interface).

From show asp drop I am informed that frames are dropped due to the following reason:

TCP failed 3 way handshake (tcp-3whs-failed)

I am not using ARP, but use the MAC address of the firewall interface, which is the default gateway.

I create the SYN, SYN-ACK and ACK like the following:

SYN: (Client (outside) to server (inside))

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 0
Acknowledgement number: 0
Synchronize: 1
Acknowledgement: 0

SYN-ACK: (Server (inside) to client (outside)) (this does not pass the firewall)

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.102.19
Destination IP: 10.1.202.1
Default Gateway: 10.1.102.254

**TCP**
Source Port: 8000
Destination Port: 9000
Sequence number: 0
Acknowledgement number: 1
Synchronize: 1
Acknowledgement: 1

ACK: (Client (outside) to server (inside))

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 1
Acknowledgement number: 1
Synchronize: 0
Acknowledgement: 1

Furthermore, my topology is like following:

The traffic generator client (outside network) is connected to a switch on which a VLAN is added. The switch is connected to the outside firewall interface. On the inside network, traffic generator is connected to the switch where VLAN tags are added and the switch is connected to the inside interface of the firewall.

Can anyone tell me why the ASA drops the SYN-ACK?

Thanks in advance!

EDIT:

As suggested by Ron Trunk, I disabled the randomization of sequence numbers by using:

random-sequence-number disable
Added capture of the inside-interface and the outside-interface.
Updated the capture files

What do you mean by packet-tracer command? I am working on an ASA Service Module. — muehsi, Jul 22 '15 at 23:56
Ah, never used that. The ASA appliance has a command "packet-tracer" that simulates a packet running through the rules. I BELIEVE it's mostly for traffic at layer 3 and up, but maybe that's just because I never had need for it on any lower layer. Question mark your way through it, but usage is essentially "packet-tracer input INCOMING-IFNAME tcp SOURCE.IP.ADDRESS.HERE SRC-PORT DST.IP.ADDRESS.HERE DST-PORT" — Smithers, Jul 23 '15 at 15:30
Yes, this is also available in ASDM. I checked that, and the packet should be passing. But I cannot choose packets for the connection setup. I can only check the IP and Port. The problem is, that TCP handshake fails. — muehsi, Jul 23 '15 at 20:19
Well that SUGGESTS your layer 3 is good, which is nice. You'll want to capture ALL traffic on the outside and inside interfaces of the ASA, including ARP. You can first confirm if the traffic is actually reaching the ingress interface, and then confirm that it's not leaving the egress--because if it IS leaving your egress, or ISN'T reaching your ingress, you've probably got a switch problem. — Smithers, Jul 24 '15 at 19:50
Thanks for your hints. I confirmed the `SYN-ACK` reaching the inside interface but being dropped by the firewall. Furthermore, I added the capture files and a network diagram. — muehsi, Jul 27 '15 at 13:57
Without the config it’s only guess work, I assume the fw is missing something — Matt Douhan, Aug 26 '20 at 09:48

score 3 · Accepted Answer · answered Jul 21 '15 at 15:59

3

By default, the ASA randomizes the sequence numbers in the handshake (to prevent session hijacks). So your sequence numbers don't actually match. You can turn off that feature.

random-sequence-number disable

answered Jul 21 '15 at 15:59

Ron Trunk

66,852
5
65
126

I added this command, didn't know it exist. Unfortunately it did not solve my problem. Wireshark says my SYN ACK has a 'ACK=3200214167' which is weird since it was captured on the interface before it passes the firewall. Does the Win=4096 in the syn packet mean anything for connection setup? – muehsi Jul 22 '15 at 21:20
The Win essentially just means there's 4kb of space available in the network buffer of the device that sent that packet. – Smithers Jul 24 '15 at 19:51
1

I notice that before the client sends a syn-ack, it sends a rst-ack. I think you need to figure that out first. – Ron Trunk Jul 27 '15 at 16:08
It did not work when I followed this [explanation](http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/conns_connlimits.html). I also had to apply the service policy to the interfaces (`service-policy interface `). Thanks for your hint. – muehsi Jul 31 '15 at 15:12

score 3 · Answer 2 · answered Jul 27 '15 at 21:21

3

In your inside capture, there are two packets going from the Server (10.1.102.19) to the Client (10.1.202.1), but they are coming from different MAC addresses.

#23 Ethernet II, Src: 00:10:94:00:00:01 (00:10:94:00:00:01), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 19112639, Len: 0

#25 Ethernet II, Src: 00:10:94:00:00:02 (00:10:94:00:00:02), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 1, Len: 0

That seems weird, but is probably not your problem. As far as I can interpret it, your problem is as follows:

It seems like the server itself naturally responds to your crafted SYN packet with the RST-ACK in packet#23 (of the inside cap, see above) -- probably because port 8000 is closed. This will prompt the Firewall to forward the RST to the Outside (Packet#23 in Outside cap), and purge this connection from its state table.

But your crafted SYN-ACK packet fires off in #25 (of the inside cap), prompting a RST from the Firewall (#26) because there is no entry in the connection table related to this flow.

answered Jul 27 '15 at 21:21

Eddie

14,808
6
42
82

Thanks for your comments. I have checked the Ethernet addresses and fixed them. As you suspected, this did not change anything. I have also inspected the problem concerning the RST-ACK and fixed it. There has been a temporary misconfiguration at the server. Nevertheless, my origin problem still occurs: The `SYN-ACK` does not pass the firewall. I have updated the capture files of the inside/outside interfaces to the current state. – muehsi Jul 30 '15 at 12:21
How did you 'fix' the RST-ACK? That is the normal/expected behavior of the server. I haven't looked at the new captures, I will try to when I find more time. – Eddie Jul 30 '15 at 14:24
1

@muehsi, looks to me like you still have a problem. AFAIK, Cloudshark (like Wireshark default) adjusts displayed sequence numbers relative to 0 for easier readability. However, your SYN-ACK from the server to the client is showing that it is ACKing 2644561697 rather than 1. Since the ACK doesn't match what the firewall expects to see, it should drop it. – YLearn Jul 30 '15 at 19:03
Regarding "normal behavior" etc. We are using a [Spirent TestCenter](http://www.spirent.com/Ethernet_Testing/Platforms/C1_Chassis) as traffic generator (for both client and server side). So the reaction, i.e., regarding behavior when no application is listening to a port might be different to a normal OS. But that's why we want this hand-crafted 3-way handshake (just as background information). – StephenKing Jul 31 '15 at 06:48

score 1 · Answer 3 · answered Jul 31 '15 at 06:24

Can you run the following on your ASA please:

// Enable all capturing for all asp drops

ASA# capture asp-drop type asp-drop all

// Show capture buffer which should identify why the handshake is failing

ASA# sh capture asp-drop

Should show something similar to the following but for your specific kind of drop:

   2 packets captured
   1: 15:15:00.682154 197.2.1.29.2616 > 87.200.42.101.443: S 1239395083:1239395083(0) win 65535 <mss 1260,nop,nop,sackOK> Drop-reason: (acl-drop) Flow is denied by configured rule
   4: 15:15:00.750830 10.70.0.162.3812 > 168.252.3.41.15: S 3523756300:3523756300(0) win 65535 <mss 1360,nop,nop,sackOK> Drop-reason: (rpf-violated) Reverse-path verify failed

Keep in mind that one basic rule for the ASA is that to initiate traffic from a lower-security interface(Outside) to a higher security interface(Inside) there must be a explicit ACL entry to allow this traffic through. Without seeing your ASA configuration it is hard to tell what could be causing the problems.

score -1 · Answer 4 · answered Jul 27 '15 at 17:12

You are describing normal/defaul operation of the ASA. Only established TCP connections are allowed from OUTSIDE to INSIDE. You can disable this by configuring TCP State Bypass.

Step 1 Choose Configuration > Firewall > Service Policy.

Step 2 Click Add > Add Service Policy Rule.

Alternatively, if you already have a rule for the hosts, edit the rule.

Step 3 Select whether to apply the rule to a specific interface or globally to all interfaces, and click Next.

Step 4 For Traffic Classification, select Source and Destination IP Addresses (uses ACL) and click Next.

Step 5 For the ACL rule, enter the IP addresses of the hosts on each end of the route in Source and Destination, and specify the protocol as TCP. Click Next when finished.

For example, if you want to bypass TCP state checking between 10.1.1.1 and 10.2.2.2, enter:

Source = 10.1.1.1
Destination = 10.2.2.2
Destination Protocol = tcp
Step 6 On the Rule Actions page, click the Connection Settings tab and select TCP State Bypass.

Step 7 Click Finish to save the rule, and Apply to update the device.

*(colleague of @muehsi speaking)* Thanks for your answer. However, I think this cannot be the reason, as other traffic (stateful TCP) that is not made by hand-crafted TCP packets from the traffic generator can pass the ASA from outside to inside. It somehow is in the nature of the packets that the trafficgen is sending. — StephenKing, Jul 27 '15 at 19:24

TCP Handshake fails on Cisco ASA

4 Answers4