Problem with VPN Policy Nat on Cisco ASA
I have a Cisco ASA policy nat issue that's vexing me. I'm trying to build a vpn between my customer's ASA and an outside vendor. My customer has an inside range of 10.1.1.x/24, so I am policy natting it on my side. My customer has a server at 10.1.1.16 that must be visible across the vpn. The vendor has asked me to nat it to 10.95.93.1. (The vendor's subnet is 10.69.100.0/24). So I've put the following lines in my config:
access-list vpn extended permit ip host 10.95.93.1 10.69.100.0 255.255.255.0
access-list nat extended permit ip host 10.1.1.16 10.69.100.0 255.255.255.0
static (inside,outside) 10.95.93.1 access-list nat
When I do a "show xlate" command I see the following:
Global 10.95.93.1 Local 10.1.1.16
That suggests my translation is working. And when I do a "show nat" command I get:
match ip inside host 10.1.1.16 outside 10.69.100.0 255.255.255.0
static translation to 10.95.93.1
translate_hits = 0, untranslate_hits = 54
I'm wondering there if the 0 translated hits is a problem or not.
The issue is this. The tunnel comes up fine. And the vendor can send traffic to me, but I send no return traffic to him. When I do a "sho crypto" command I see the following:
Crypto map tag: VPN, seq num: 3, local addr: 64.69.xxx.xxx
access-list vpn permit ip host 10.95.93.1 10.69.100.0 255.255.255.0
local ident (addr/mask/prot/port): (10.95.93.1/255.255.255.25
remote ident (addr/mask/prot/port): (10.69.100.0/255.255.255.0
current_peer: 198.245.xxx.xxx
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 169, #pkts decrypt: 169, #pkts verify: 169
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
So I have gotten 169 packets but haven't sent any back. And in my log files I'm seeing the following:
Jan 22 2009 13:04:50: %ASA-3-106014: Deny inbound icmp src inside:10.1.1.16 dst inside:10.69.100.54 (type 0, code 0)
That seems odd to me, as the 10.69.100.54 address shouldn't show as an "inside" address if it's the other end of a vpn tunnel, should it?
It seems like something isn't set quite right.
Ben
access-list vpn extended permit ip host 10.95.93.1 10.69.100.0 255.255.255.0
access-list nat extended permit ip host 10.1.1.16 10.69.100.0 255.255.255.0
static (inside,outside) 10.95.93.1 access-list nat
When I do a "show xlate" command I see the following:
Global 10.95.93.1 Local 10.1.1.16
That suggests my translation is working. And when I do a "show nat" command I get:
match ip inside host 10.1.1.16 outside 10.69.100.0 255.255.255.0
static translation to 10.95.93.1
translate_hits = 0, untranslate_hits = 54
I'm wondering there if the 0 translated hits is a problem or not.
The issue is this. The tunnel comes up fine. And the vendor can send traffic to me, but I send no return traffic to him. When I do a "sho crypto" command I see the following:
Crypto map tag: VPN, seq num: 3, local addr: 64.69.xxx.xxx
access-list vpn permit ip host 10.95.93.1 10.69.100.0 255.255.255.0
local ident (addr/mask/prot/port): (10.95.93.1/255.255.255.25
remote ident (addr/mask/prot/port): (10.69.100.0/255.255.255.0
current_peer: 198.245.xxx.xxx
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 169, #pkts decrypt: 169, #pkts verify: 169
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
So I have gotten 169 packets but haven't sent any back. And in my log files I'm seeing the following:
Jan 22 2009 13:04:50: %ASA-3-106014: Deny inbound icmp src inside:10.1.1.16 dst inside:10.69.100.54 (type 0, code 0)
That seems odd to me, as the 10.69.100.54 address shouldn't show as an "inside" address if it's the other end of a vpn tunnel, should it?
It seems like something isn't set quite right.
Ben
Last Comment
ASKER
Thanks JFrederick29.
Not sure about adding the route though:
route outside 10.69.100.0 255.255.255.0 <outside next hop>
I've built probably a thousand vpn tunnels on Pixes and ASAs over the past ten years and never had to do that. (In fact, I've built tunnels with exactly this kind of policy natting on old Pix 6.3 code and had it work fine.) The traffic to that subnet should traverse the vpn tunnel once it's established.
The routing internal to the 10.1.1.x network is good as this is the only path out of the network. So the default route covers it. (And if the routing were wrong I wouldn't be seeing the error messages in my log files.)
Ben
Not sure about adding the route though:
route outside 10.69.100.0 255.255.255.0 <outside next hop>
I've built probably a thousand vpn tunnels on Pixes and ASAs over the past ten years and never had to do that. (In fact, I've built tunnels with exactly this kind of policy natting on old Pix 6.3 code and had it work fine.) The traffic to that subnet should traverse the vpn tunnel once it's established.
The routing internal to the 10.1.1.x network is good as this is the only path out of the network. So the default route covers it. (And if the routing were wrong I wouldn't be seeing the error messages in my log files.)
Ben
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Arrrg . . .
". . . and no 10.x.x.x routes to the inside," Crap, that was it. I had a summarized route pointing all 10.0.0.0/8 traffic back to their internal WAN router. I didn't think to look there as I normally never do that for exactly this reason. But after you said that I went back and checked and that was it.
I hate it when it's the dumb stuff.
Thanks for your help.
Ben
". . . and no 10.x.x.x routes to the inside," Crap, that was it. I had a summarized route pointing all 10.0.0.0/8 traffic back to their internal WAN router. I didn't think to look there as I normally never do that for exactly this reason. But after you said that I went back and checked and that was it.
I hate it when it's the dumb stuff.
Thanks for your help.
Ben
Hardware Firewalls
Hardware-based firewalls provide more sophisticated protection for inbound and outbound traffic than the simple Windows software firewall or the basic NAT firewalls found in routers. These devices implement techniques such as stateful packet inspection, deep packet inspection, and content filtering; and may include built-in antivirus and anti-malware protection.
25K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
Make sure the ASA has a route to the vendor subnet via the outside interface:
route outside 10.69.100.0 255.255.255.0 <outside next hop>
Also, verify their is routing on the inside to the 10.69.100.0/24 subnet via this ASA if it is not "the" Internet Firewall that the inside default route/gateway points to.