cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1083
Views
0
Helpful
2
Replies

Remote VPN on ASA failing to hit public servers

leelove01
Level 1
Level 1

Guys,

Thanks for reading this post.   I have a Cisco ASA 5510 that was set up as a VPN server for working remote.  I have disabled split tunneling so that all traffic created while VPN'd in goes through the ASA.  The problem I'm having I believe would be resolved if I enabled split tunneling but I would prefer another solution.  Now..for the problem.

When a user is connected via VPN, they can hit all intended devices both public and private accept servers that have static NATs in the FW.  So Server A has a public of 1.1.1.1 which is one to one mapped to private address of 10.1.1.1.  Now if the remote user brings up a browser and goes to 1.1.1.1 it wont work.  The FW gives me a error which is posted below.  However, using the private IP of the server works.  I thought about trying to manipulate DNS to resolve this as the remote users are using URLs and not IPs when trying to reach these servers but again, was hoping I could resolve the NAT problem that the FW seems to be having.  Any help greatly appreciated. 

Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src Outside:192.168.202.100/49238 dst INSIDE:1.1.1.1/80 denied due to NAT reverse path failure

192.168.202.x/24 is the remote vpn ip given via the ASA. 

__________________________________________________________________

Here are some configurations on the ASA that might help

static (INSIDE,Outside) 1.1.1.1 10.1.1.1 netmask 255.255.255.255

access-list INSIDE_nat0_outbound extended permit ip object-group DM_INLINE_NETWORK_2 192.168.202.0 255.255.255.0

object-group network DM_INLINE_NETWORK_2

network-object 10.1.1.0 255.255.255.0    <---network of where the host sits,   this allows the vpn users to communicate via private ips to the servers.

network-object 172.1.1.0 255.255.255.0

network-object 192.168.0.0 255.255.255.0

nat (Outside) 1 192.168.202.0 255.255.255.0 <--set up to NAT vpn traffic destined to the internet (which includes my networks public ips. ) 

ASA has 2 interfaces that are in play in the situation..

Outside with 4.4.4.4 as the public ip traffic gets NAT'd do dynamically

Inside with 10.1.1.x network on it.

The ASA is running 8.2

1 Accepted Solution

Accepted Solutions

mirober2
Cisco Employee
Cisco Employee

Hello,

The ASA requires that traffic matches the same NAT rule in both the forward and reverse direction. In your case, if 192.168.202.100 tries to access 1.1.1.1, it will match 2 different rules:

192.168.202.100 -> 1.1.1.1:

static (INSIDE,Outside) 1.1.1.1 10.1.1.1 netmask 255.255.255.255

10.1.1.1 -> 192.168.202.100:

nat (INSIDE) 0 access-list INSIDE_nat0_outbound

The forward direction says that the destination should be 1.1.1.1 and untranslated to 10.1.1.1.

The reverse direction says that the server's address should always be 10.1.1.1 and not be translated to 1.1.1.1 if it talks to the remote VPN subnet.

This would fail since the inbound packet would be destined to 1.1.1.1, but the return traffic would be sourced from 10.1.1.1. With the current config, VPN users should be connecting to 10.1.1.1 instead of 1.1.1.1. Otherwise, you need to adjust your NAT 0 configuration to not exempt this flow from static NAT:

access-list INSIDE_nat0_outbound line 1 deny ip host 10.1.1.1 192.168.202.0 255.255.255.0

-Mike

View solution in original post

2 Replies 2

mirober2
Cisco Employee
Cisco Employee

Hello,

The ASA requires that traffic matches the same NAT rule in both the forward and reverse direction. In your case, if 192.168.202.100 tries to access 1.1.1.1, it will match 2 different rules:

192.168.202.100 -> 1.1.1.1:

static (INSIDE,Outside) 1.1.1.1 10.1.1.1 netmask 255.255.255.255

10.1.1.1 -> 192.168.202.100:

nat (INSIDE) 0 access-list INSIDE_nat0_outbound

The forward direction says that the destination should be 1.1.1.1 and untranslated to 10.1.1.1.

The reverse direction says that the server's address should always be 10.1.1.1 and not be translated to 1.1.1.1 if it talks to the remote VPN subnet.

This would fail since the inbound packet would be destined to 1.1.1.1, but the return traffic would be sourced from 10.1.1.1. With the current config, VPN users should be connecting to 10.1.1.1 instead of 1.1.1.1. Otherwise, you need to adjust your NAT 0 configuration to not exempt this flow from static NAT:

access-list INSIDE_nat0_outbound line 1 deny ip host 10.1.1.1 192.168.202.0 255.255.255.0

-Mike

Mike,

Thats awesome.  After reading your post I realized where it was hanging up at.  Thanks for the help.  I have since tested your solution and it works.  This has added to my knowledge base on how the ASA works and views NAT.  Thanks a bunch. 

Lee

Review Cisco Networking products for a $25 gift card