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.
Solved! Go to Solution.
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?
I know this isn't ideal, but is this a way around the issue:
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
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.
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.
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?
- 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.
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.