topic Re: SYN ACK Flags blocked in Network Security

SYN ACK Flags blocked

Robert Craig — Mon, 11 Mar 2019 22:09:39 GMT

OK, strange problem starting appearing recently. I can't for the life of me remember what I could have possibly changed to cause this problem. Below is architecture.

Internet---Cisco 2600 (Dynamic IP)--PIX 515E----Interface VLAN2 (192.168.2.1)----Wireless Router (local lan 192.168.3.0)

I am using my laptop and trying to access a device on the VLAN2 network and can't. I can ping all day long, but nothing beyond that. The only thing appearing in my logs is the below

Deny TCP (no connection) from 192.168.2.5/2000 to 192.168.3.100/35670 flags SYN ACK on interface vlan2

I've looked in the interface configs and made sure that "traffic between two more interfaces with same security levels" is configured and looked everywhere else. This problem just started and really doesn't make any sense. Anyone know where I can doublecheck? Thanks for any help.

Robert

SYN ACK Flags blocked

Julio Carvajal — Tue, 03 Jan 2012 23:48:45 GMT

Hello Robert,

The connection is being closed because the ASA is receiving a Syn ACK packet that he was not expecting to receive ( No Syn packet, No connection).

You need to configure U-turning or a TCP bypass rule.

What version are you running??

Do rate helpful posts!!!!

Regards,

Julio

Re: SYN ACK Flags blocked

Robert Craig — Wed, 04 Jan 2012 00:38:06 GMT

Version 8.0(4). I’ve never configured either one of those. Any pointers?

Robert

Re: SYN ACK Flags blocked

Julio Carvajal — Wed, 04 Jan 2012 00:51:34 GMT

Can I have a diagram of your network with the internal ip address of both devices ( the ones are trying to communicate on the same interface and each default gateway)

Regards,

Re: SYN ACK Flags blocked

Robert Craig — Wed, 04 Jan 2012 02:26:24 GMT

Not a problem. Attached is a diagram I threw together. Basically, laptop on wireless is 192.168.3.100 is trying to access anything on VLAN2. I can't ping or do anything, but can out to the internet and anything else on the network no problem, to include the 192.168.1.0 network. It's almost like 192.168.2.0 and 3.0 aren't allowed to talk to each other. In the diagram, the server represents a Cisco Call Manager, 192.168.2.5.

Re: SYN ACK Flags blocked

Julio Carvajal — Wed, 04 Jan 2012 03:18:07 GMT

Hello Robert,

So problem is with the communication from 192.168.2.0 and 3.0!!

Here is the thing!!

When a packet from the wireless local network host tries to go to 192.168.2.x the packet will go to the wireless router and then as he is on the same network he will send it to the host(Syn)

The host will send the (Syn Ack) to thedefautl gateway = ASA, the ASA will say wait a minute a SYN ACK but where is the SYN, and Drop the packet the session does not get established.

So in order to allow this communication to be biderectional lets do a tcp state bypass:

access-list test permit tcp 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0

class-map tcp_bypass

match access-list test

policy-map global_policy

class tcp_bypass

set connection advanced-option tcp-state-bypass

Do rate helpful posts

Julio

Re: SYN ACK Flags blocked

Robert Craig — Wed, 04 Jan 2012 14:13:36 GMT

Julio,

I’m almost there. I figured out I had to manually create the TCP Map “tcp-state-bypass”. However, even with no options selected (I am doing this in ASDM), traffic still won’t go through. I’ve messed with several settings in the tcp map, but no luck.

Robert

Re: SYN ACK Flags blocked

Julio Carvajal — Wed, 04 Jan 2012 15:05:13 GMT

Hello Robert,

Is there a way you could do it via CLI, you just will need to copy paste the information I have provided you....

Regards,

Julio

Re: SYN ACK Flags blocked

Robert Craig — Wed, 04 Jan 2012 15:14:37 GMT

That’s what I tried first. I got stuck at the tcp-state-bypass command. It said no TCP map exists. I did some digging on Cisco. I should have that option in ASDM under a new TCP MAP as well under the Advanced section. For whatever reason, it doesn’t exist. Just to make sure we are on the same page, I am using a PIX 515E running IOS 8.0(4) with ASDM 6.1.5. According to all of the documentation, the bypass command should work, but it isn’t. Any ideas?

Robert

Re: SYN ACK Flags blocked

Julio Carvajal — Wed, 04 Jan 2012 17:06:07 GMT

Hello Robert,

I know what you mean! but the pix should take the command, on the TCP map options we do not configure the TCP state bypass.

Please confirm if you are doing it like this

policy-map global_policy

class test

set connection advanced-options tcp-state-bypass

Regards,

Julio

Re: SYN ACK Flags blocked

Robert Craig — Wed, 04 Jan 2012 19:42:37 GMT

Julio,

Even used the tab button to make sure I am putting the commands in correctly. But, as soon as I press enter on that statement I get “ERROR: Can’t find map tcp-state-bypass”

Robert

SYN ACK Flags blocked

Julio Carvajal — Thu, 05 Jan 2012 05:51:53 GMT

Hello Robert,

After doing a little of research I got the answer of why this is not possible, TCP state-bypass is a feature available until 8.2....

Let me do a little bit of research on this.

Julio

Re: SYN ACK Flags blocked

Robert Craig — Thu, 05 Jan 2012 12:22:08 GMT

OK, that would make sense why all of the documentation online references an ASA, not a PIX. Let me know what you find. Thanks Julio!

Robert

Re: SYN ACK Flags blocked

mirober2 — Thu, 05 Jan 2012 15:45:05 GMT

Hi Robert,

Just to add some background to the thread, this document explains why this problem occurs and suggests a few mitigation techniques that you might find useful:

https://supportforums.cisco.com/docs/DOC-14491

-Mike

Re: SYN ACK Flags blocked

Robert Craig — Thu, 05 Jan 2012 19:35:36 GMT

Hey Mike. Thanks for the link. Unfortunately, if I am reading the document right, it only applies to NAT statements. I have a router in front of this firewall so I'm not using NAT at the firewall level. I tried to apply the command to the only two NAT statements I have (listed below) and it won't let me because of the 0 in the statement.

nat (inside) 0 access-list inside_nat0_outbound

nat (VLAN2) 0 access-list VLAN2_nat0_outbound

If I understand these statements correctly, it simply means DO NOT NAT traffic going out from these interfaces.

Re: SYN ACK Flags blocked

mirober2 — Thu, 05 Jan 2012 20:22:50 GMT

Hi Robert,

The problem is actually a routing issue and is unrelated to NAT, though NAT can certainly contribute to the problem. You are correct that NAT 0 statements mean that any traffic matching the ACLs will not be translated, but again this would not necessarily be a fix for the problem of asymmetric routing.

-Mike

Re: SYN ACK Flags blocked

Robert Craig — Thu, 05 Jan 2012 20:27:36 GMT

Mike,

Is this a design flaw or something on my end? I put a static route from the inside interface to the perimeter interface of my wireless router. Traffic works great both ways except for the way I mentioned earlier. I'm really at a loss here on how to resolve this.

Robert

Re: SYN ACK Flags blocked

mirober2 — Thu, 05 Jan 2012 20:51:03 GMT

Hi Robert,

Based on the syslog you posted originally, the problem is that traffic sourced from 192.168.3.100 destined to 192.168.2.5 does not go through the firewall at all. The ASA is only seeing traffic sourced from 192.168.2.5 destined to 192.168.3.100. Since the ASA can only see half of the bi-directional connection, it cannot properly firewall the traffic and thus drops the packets.

The solution is to fix the routing in your design such that either a) 192.168.3.100 sends traffic through the firewall before it reaches 192.168.2.5, or b) 192.168.2.5 does not send traffic for 192.168.3.100 through the firewall at all.

As Julio mentioned, TCP state bypass can be used to configure the ASA to ignore this problem and pass the traffic anyway, but this is just a workaround. Since the PIX doesn't support this feature, the workarounds listed in the above document can help get things working for you until you're ready to adjust the routing config.

-Mike

Re: SYN ACK Flags blocked

Robert Craig — Thu, 05 Jan 2012 21:37:37 GMT

I see what you are saying, but unfortunately I don’t understand how to implement a routing change like that. Consider this. Interface inside is 192.168.1.1. The Wireless router (internet interface) is 192.168.1.7. Now, clients on the wireless side get an IP from the wireless router on the 192.168.3.0 network. Now, 3.0 can go through the firewall and access something on another vlan or another interface no problem. But, the problem is accessing devices on the 1.0 network. I rebuilt the PIX last night because there were some things going on other than this that I couldn’t rectify. The wireless router only has a default route (as it should in this case) and that is to 192.168.1.1. So, in this situation, how would I adjust the routing if it has to go to 1.1 no matter what?

Robert

Re: SYN ACK Flags blocked

mirober2 — Thu, 05 Jan 2012 22:03:28 GMT

Hi Robert,

If I understand the network correctly based on the above posts, you have something like this (correct me if I'm wrong):

Internet---Router---(outside)PIX(inside)---VLAN 1

(vlan2)

VLAN 2

Wireless Router

VLAN 3

Wireless hosts

Assuming this is correct, the problem happens when wireless hosts (192.168.3.x) talk to VLAN 2 hosts (192.168.2.x), right? So the problem looks like this:

1. 192.168.3.x sends a packet for 192.168.2.x to it's default gateway (the wireless router).

2. The wireless router checks its routing table and sees that it already has an interface in the 192.168.2.x subnet, so it sends the packet directly to the destination. The PIX never sees this initial packet.

3. 192.168.2.x needs to send its response destined to 192.168.3.x. It checks its routing table and sees that it has a default gateway configured on the host that points to the PIX's VLAN 2 interface.

4. The PIX receives the packet but knowing that it never saw the SYN for the connection, it drops the 192.168.2.x host's response and the connection fails.

To fix this, you have a couple of options:

1. Add a static route on the hosts in the 192.168.2.x network that sends all traffic for 192.168.3.x to the Wireless router's interface, instead of the PIX's interface. For example, on MS Windows, this is done with the 'route add' command.

2. Add a static route on the Wireless Router that sends all traffic destined for 192.168.2.x to the PIX's interface instead of directly to the hosts themselves. If you choose this option, you also need to enable the 'same-security-traffic permit intra-interface' command on the PIX to allow the packet to enter and leave on the same VLAN 2 interface (this is denied by default). You also need to make sure the packet is allowed by your security policy (ACLs, NAT, etc.)

-Mike