7

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

Improve this question
7
  • What does packet-tracer command show?
    – Smithers
    Commented Jul 21, 2015 at 17:54
  • What do you mean by packet-tracer command? I am working on an ASA Service Module.
    – muehsi
    Commented Jul 22, 2015 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
    Commented Jul 23, 2015 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
    Commented Jul 23, 2015 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
    Commented Jul 24, 2015 at 19:50

4 Answers 4

Reset to default
3
+50

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
Improve this answer
4
  • 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
    Commented Jul 22, 2015 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
    Commented Jul 24, 2015 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
    Commented Jul 27, 2015 at 16:08
  • It did not work when I followed this explanation. I also had to apply the service policy to the interfaces (service-policy <name> interface <interface>). Thanks for your hint.
    – muehsi
    Commented Jul 31, 2015 at 15:12
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.

Improve this answer
4
  • 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
    Commented Jul 30, 2015 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
    Commented Jul 30, 2015 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
    Commented Jul 30, 2015 at 19:03
  • Regarding "normal behavior" etc. We are using a Spirent TestCenter 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
    Commented Jul 31, 2015 at 6:48
1

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.

Improve this answer
-1

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.
Improve this answer
1
  • (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
    Commented Jul 27, 2015 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.