Avatar of cns13
cns13Flag for United States of America asked on

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.255/0/0)
      remote ident (addr/mask/prot/port): (10.69.100.0/255.255.255.0/0/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
Hardware Firewalls

Avatar of undefined
Last Comment
cns13

8/22/2022 - Mon
JFrederick29

Config looks good and you are right in your thinking that traffic is coming in but no return traffic is making it back over the tunnel.

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.
ASKER
cns13

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
ASKER CERTIFIED SOLUTION
JFrederick29

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
ASKER
cns13

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
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy