Overlapping address space issue - how to NAT inside traffic to different address range on ASA for VPN comms with 3rd party?

[mitchen]

We already have site-to-site IPSEC VPN connectivity with a 3rd party.

They need to be able to access a couple of servers on our internal network but the problem is, the subnet these servers are hosted on clashes with address space they already have in use elsewhere. So, they have asked if we can set up a new subnet and have our ASA firewall (running v7.2) NAT the traffic from/to the "real" internal addresses of our servers.

e.g.

• 3rd party subnet 10.10.10.0/24
  
• Our subnet 10.20.20.0/24 (but this clashes with address space 3rd party have elsewhwere)
  
• Our "real" internal server addresses are 10.20.20.1 and 10.20.20.2
  

How would we set-up NAT on our ASA to translate the "real" internal addresses of these servers to some other addresses which don't clash?

i.e. as far as the 3rd party is concerned, they would simply have to communicate with this "new" subnet, say, 192.168.20.0/24 and our ASA firewall would NAT the traffic accordingly to allow comms to take place?

(And this should only affect comms to these servers for the 3rd party - NOT for any of our other multiple VPN connections! And shouldn't affect any other comms from the servers themselves!)

This is what I have tried so far, for one of the servers, without any success:

On ASA:

!

access-list 3rdpartysite line 1 extended permit ip host 192.168.20.1 10.10.10.0 255.255.255.0
!
access-list SERVER-NAT line 1 extended permit ip host 10.20.20.1 10.10.10.0 255.255.255.0
!
static (inside,outside) 192.168.20.1 access-list SERVER-NAT

"sh xlate" shows:

Global 192.168.20.1 Local 10.20.20.1

Can anyone help with the necessary NAT configurations on the ASA?

Thanks!

[Jennifer Halim]

Yup, that looks correct to me on your end.

Does the 3rd party side has the mirror image ACL for the crypto ACl, as well as NAT exemption to 192.168.20.1?

Where is it failing?

Is the tunnel UP? Can you share the output of :

show cry isa sa

show cry ipsec sa

[mitchen]

Hi Jennifer,

thanks for the reply.

I'm actually just trying to test it out first before going back to the 3rd party side so, at the moment, using one of my own routers (cisco 877) connected via IPSEC VPN.  I have the following mirror image crypto ACL on the router:

permit ip host 10.10.10.0 255.255.255.0 host 192.168.20.1

And the following NAT exemption:

deny ip 10.10.10.0 255.255.255.0 host 192.168.20.1

I was a bit confused on the NAT exemption for my side on the ASA.  Do I still need to include a NAT exemption line e.g.

access-list inside_nat0_outbound extended permit ip host 192.168.20.1 10.10.10.0 255.255.255.0

I'm trying to test simply by pinging the 192.168.20.1 address from my remote router (but it just times out)

On the remote router (i.e. this would be the 3rd party side in reality) I see the following for sh crypto ipsec sa:

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (192.168.20.1/255.255.255.255/0/0)

   current_peer 195.80.13.162 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 1, #recv errors 0

On the ASA, the sh crypto ipsec sa shows:

access-list 3rdpartysite extended permit ip host 192.168.20.1 10.10.10.0 255.255.255.0
    local ident (addr/mask/prot/port): (192.168.20.1/255.255.255.255/0/0)
      remote ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #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

Any more advice/suggestions would be greatly appreciated!

[Jennifer Halim]

No, you don't need the NAT exemption below:

access-list inside_nat0_outbound extended permit ip host 192.168.20.1 10.10.10.0 255.255.255.0

And also if you have NAT exemption that has the following configured:

access-list inside_nat0_outbound extended permit ip 10.20.20.0 255.255.255.0 10.10.10.0 255.255.255.0

--> remove that line as well.

From the output above, it seems that the traffic is getting towards the ASA and gets decrypted, but there is no reply back.

Make sure that your host 10.20.20.1 knows how to route back towards 10.10.10.0/24 and also if it has windows fw enabled, pls disable it temporarily to allow inbound connection.

[mitchen]

I've taken out the NAT exemption (and checked that I don't have the other NAT exemption line) but it's still the same.

There's no Windows FW enabled on the host.

Interestingly, if I try to initiate the ping from the Windows Host over to my router (i.e. the router acting as the "3rdparty site") e.g.

From "real address" 10.20.20.1 I try to ping 10.10.10.1 then it still times out.

However, I don't see any packets getting encrypted and sent by the ASA over to the router.  (What I expect/want to happen is that the ASA sees the traffic from 10.20.20.1 and translates it to 192.168.20.1 before sending it back to 10.10.10.1)

The host 10.20.20.1 sends to a default gateway (our network switch) which in turn routes traffic directly to the ASA so it should know how to get to the 10.10.10.0/24 subnet (I think!)

So, it seems like traffic from 3rd party to ASA is going through and being translated but traffic going back again is not?

Is this likely routing or translation issue?

Do I need something specific set up on the ASA regards routing to the translated address 192.168.20.1?

[Jennifer Halim · Accepted solution]

Did you "clear xlate" after configuring the NAT statements?

When you try to ping from the 10.20.20.1, does it get to the ASA? Do you have any ACL on that interface that might be blocking the ping? Also, can you run packet capture on the ASA to see if the ASA is even receiving the traffic?

What is the subnet mask of the 10.20.20.1 host? I assume it's 255.255.255.0?

You don't need anything specific on the ASA in regards to routing the 192.168.20.1.

[mitchen]

Hi Jennifer,

I hadn't tried "clear xlate" after configuring the NAT statements - but just tried it there and, what do you know, it's sprung into life!  (I hadn't expected it to be something so straightforward that would fix it, was sure I must have been going wrong somewhere!)

Thanks very much for your assistance on this - greatly appreciated!

[Jennifer Halim]

Excellent, great news and thanks for the update and rating.