Deny TCP (no connection)

[Mark Cavendish]

Hi

We currently have a new issue where users on our VPN subnet cannot connect to certain servers in the DMZ. Ie they cannot RDP or connect via HTTPS. Users on the local LAN subnets can connect fine.

The new DMZ servers are in the same firewall rules as the existing DMZ servers which users on the VPN subnet can access fine. I tried some tests and the DMZ server can ping, traceroute and connect to all ports on the VPN PC. The VPN PC can ping and traceroute to the DMZ server, but it cannot connect to any ports. Everytime I get this error in the logs:

6

Jul 07 2015

15:35:00

106015

10.95.22.45

443

10.225.0.74

19624

Deny TCP (no connection) from 10.95.22.45/443 to 10.225.0.74/19624 flags SYN ACK on interface DMZ

It seems to be a routing issue and some posts say it is an asymmetrical issue. What I can't understand is how certain other DMZ hosts can be reached on the 10.95.22.0 subnet without any issues. 

If anyone could point me in the right direction on how to solve this it would be much appreciated.

Kind regards,

Mark 

[Akshay Rastogi · Accepted solution]

Hi Mark,

This log says that the connection was cleared form ASA before that SYN-ACK packet reached firewall.

- Could you please share your config with working an non-working DMZ servers.

It looks like asymmetric routing issue.

Regards,

Akshay Rastogi

[Mark Cavendish]

Hi Akshay

Thanks for getting back to me.

​Interestingly our VPN is managed by a separate firewall within the DMZ by BT and is also on a 10.95.22.x subnet, so the above makes sense. The VPN firewall is allowed fully through our firewall (due to our ISP setup) and it has a DMZ address that is Natted to a public IP which users connect on.  

I have had a further chance to narrow down the problem and it seems anything in the DMZ without a public IP (via NAT) isn't accessible by anyone on a VPN address which is on 10.225.x.x. Yet I just assigned 10.95.22.45 a public IP and it still doesn't work from the VPN, but other DMZ hosts still work fine.

I have attached a diagram which probably explains it better. We don't have access to the VPN firewall and it is a lengthy process to get any config changes made on it. I know the firewall is stateful and doing what is is suppose to do, but is there a way around this issue?

Kind regards,

Mark

[Mark Cavendish]

I know this isn't ideal, but is this a way around the issue:

TCP State Bypass

Specifically for TCP-based connections, disabling stateful TCP checks can help mitigate asymmetric routing. When TCP state checks are disabled, the ASA can allow packets in a TCP connection even if the ASA didn't see the entire TCP 3-way handshake. This feature is called TCP State Bypass (introduced in ASA 8.2).

ASA(config)# access-list tcp_bypass extended permit tcp 192.168.1.0 255.255.255.0 any
ASA(config)# class-map tcp_bypass
ASA(config-cmap)# match access-list tcp_bypass
ASA(config-cmap)# policy-map tcp_bypass_policy
ASA(config-pmap)# class tcp_bypass
ASA(config-pmap-c)# set connection advanced-options tcp-state-bypass
ASA(config-pmap-c)# set connection timeout idle 0:10:00
ASA(config-pmap-c)# service-policy tcp_bypass_policy inside

[Mark Cavendish]

So would this below fix the issue and tie it down specifically to the hosts affected?

asa01(config)# access-list tcp_bypass extended permit tcp 10.225.0.0 255.255.0.0 10.95.22.0 255.255.255.0
asa01(config)# class-map tcp_bypass
asa01(config-cmap)# match access-list tcp_bypass
asa01(config-cmap)# policy-map tcp_bypass_policy
asa01(config-pmap)# class tcp_bypass
asa01(config-pmap-c)# set connection advanced-options tcp-state-bypass
asa01(config-pmap-c)# service-policy tcp_bypass_policy interface DMZ
asa01(config)#

We recently upgraded our firewalls and I think this may have been introduced in 8.2 which explains why we have never noticed it before, but also strange the old hosts continue to work.

Many thanks in advance. 

[Akshay Rastogi]

Hi Mark,

As per the explanation, we could not be sure what route it might have taken and how vpn traffic is being classified, but we could confirm the asymmetric issue by configuring tcp-state-bypass. Explanation is correct 'it disable tcp state check'. 

The last configuration mentioned should work for you and it would tie to down to the host mentioned in access-list.

For once if it doesn't work, then use access-list for 'any any' but tie it to DMZ interface only. If this works, then you could check the traffic that needs to be allowed in the access-list or recommendation would be to find out the asymmetric route in the network.

Regards,

Akshay Rastogi

[Mark Cavendish]

Hi Akshay

Thanks again for confirming that.

I just entered the rule and I still got the same error message. I just amended it to any any as you mentioned and I now get:

6Jul 08 201515:50:5430230310.95.22.4544310.225.0.17322161Built TCP state-bypass connection 114805251 from DMZ:10.95.22.45/443 (10.95.22.45/443) to Private:10.225.0.173/22161 (10.225.0.173 /22161)

Yet it still doesn't allow the connection from the VPN client. Seems I am close, but missing some other configuration?

Kind regards,

Mark

[Akshay Rastogi]

Hi Mark,

- Can you take capture on Server side and see if all the packets are being exchanged?

- Also can you check the connection entry for the same 'show conn address <ip-address> and share the output here.

- Also as you have configured one public ip for your host. Can you remove that configuration and then try.

- Also i could see from the diagram that you are using two ASA. Can you check connections and logs on both the ASA.

- Also you could try with configuring tcp-bypass on another ASA as well if it is possible. This would kind of give us the idea where we have asymmetric routing.

Regards,

Akshay Rastogi

[Mark Cavendish]

Hi Akshay

Sorry to for the delay in getting back, I have finally had some success with this.

I added a static route on the DMZ box pointing 10.225.0.0 to the VPN firewall (10.95.22.5) and the VPN clients could then connect to the box. 

Unfortunately the VPN firewall isn't managed by us and we have no access to it. Whilst it is working for now, I am going to see if I can adjust the static routes on our firewall as 10.225.0.0 traffic points to the office router and I am going to see if this can be tweaked to the above and see if it breaks anything else.

So thanks again for all your help.

Regards,

Mark

[Akshay Rastogi]

Hi Mark,

I am glad that the issue is resolved.

Regards,

Akshay Rastogi