Help with new nat over vpn ver 9.1

[John Blakley]

All,

I'm trying to get familiar when this new nat format that Cisco has went to. I can't seem to figure out how to nat over a vpn tunnel using a vpnclient, although I'm not sure I'd be able to. Here's what I have:

ASA 5505 running 9.1(4). I'm using the vpnclient on the ASA, and I'd like to nat my network to something else over the vpn tunnel. I can do this with nat on a L2L tunnel on the old version of code, although I've never tried it with the ezvpn client so I'm not sure that's possible at all. I've not been able to find any examples, and I can only assume that the ASA cannot nat in network extension mode due to the fact that you're actually being pushed a policy from the headend.

Does anyone have a good link that shows how to nat over a vpn tunnel with this new format of nat?

Thanks!

John

[Jouni Forss]

Hi,

Been a long time since I have dealt with a Hardware VPN Client setup. And so far they have all been with the older 8.2 (or older) software levels. Though I think there was one discussion atleast here with the newer software.

If I am not totally mistaken the Client ASA actually creates a NAT rule dynamically. Can't remember for sure and on a quick glance the configuration guide makes no mention of NAT in the section related to Easy VPN.

Could you confirm this from the Client ASA when it has the VPN connection active by taking the output of

show run nat

show nat detal

If the Client itself inserts the NAT rule them I am not sure if its something we could override by inserting the Static Policy NAT at the very top of the Clients rules.

Then again I was thinking that maybe you could do this translation actually on the central/server side which could possibly avoid the whole issue you might have configuring this on the Client side.

In general if you were to configure a Static Policy NAT to NAT your whole LAN network to something else for a VPN connection you would use this format

object network LAN

subnet 10.10.10.0 255.255.255.0

object network LAN-NAT

subnet 192.168.10.0 255.255.255.0

object network REMOTE-LAN

subnet 10.10.20.0 255.255.255.0

nat (inside,outside) source static LAN LAN-NAT destination static REMOTE-LAN REMOTE-LAN

In the above case you would naturally doing the NAT for the LAN network located locally on this ASA. If we needed to configure a NAT that actually does NAT at the central site for the remote LAN network then we would have to configure

object network LAN

subnet 10.10.10.0 255.255.255.0

object network REMOTE-LAN

subnet 10.10.20.0 255.255.255.0

object network REMOTE-LAN-NAT

subnet 192.168.20.0 255.255.255.0

nat (inside,outside) source static LAN LAN destination static REMOTE-LAN-NAT REMOTE-LAN

But I guess its better to check what the situation is on the actual Client ASA before adding any configurations.

- Jouni

[John Blakley]

Thanks Jouni. Here's what I've got so far from playing around with it last night, and then I'll explain the oddities:

object-group network OtherSide

network-object 10.1.0.0 255.255.0.0

object network LAN-VPN

subnet 10.20.1.0 255.255.255.0

object network LAN-VPN-Translated

subnet 10.40.1.0 255.255.255.0

nat (inside,outside) source static LAN-VPN LAN-VPN-Translated destination static OtherSide OtherSide

access-list Connect extended permit ip object LAN-VPN-Translated object-group OtherSide

crypto ipsec ikev1 transform-set ESP-OtherSide esp-aes-256 esp-sha-hmac

crypto ipsec security-association pmtu-aging infinite

crypto map OUTSIDE 100 match address Connect

crypto map OUTSIDE 100 set peer x.x.x.x

crypto map OUTSIDE 100 set ikev1 transform-set ESP-OtherSide

crypto map OUTSIDE 100 set security-association lifetime seconds 28800

crypto map OUTSIDE 100 set security-association lifetime kilobytes 4608000

crypto map OUTSIDE 100 set reverse-route

crypto map OUTSIDE interface outside

crypto ca trustpool policy

crypto isakmp identity hostname

crypto ikev1 enable outside

crypto ikev1 policy 10

authentication pre-share

encryption aes

hash sha

group 2

lifetime 86400

So, here's the odd thing that I seriously don't understand and am thinking about creating a tac case on. I've decided to move away from the vpnclient since it didn't look like I could control natting. You're correct in that it pushes a nat policy under nat 0 like _vpn_acl or something like that. That being said, I moved to a L2L tunnel and have some very weird results.

VPN-Main is running 8.2(5) and VPN-Client is running 9.1(4) - config for client is above.

From vpn-main I can ping 10.40.1.40 which is a natted server on my side - the real address is 10.20.1.40. From the 10.20.1.40 server, I cannot ping 10.1.1.50 which is the inside interface of vpn-main. From vpn-main, I CAN ping 10.40.1.40 sourcing from the inside interface of vpn-main, and I can get responses:

VPN-Main(config)# ping insid 10.40.1.40

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.40.1.40, timeout is 2 seconds:

!!!!!

From vpn-client, I cannot ping vpn-main sourcing from its inside interface:

ISIS(config)# ping inside 10.1.1.50

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.50, timeout is 2 seconds:

?????

Below are the SAs for this subnet:

      access-list OtherSide extended permit ip 10.40.1.0 255.255.255.0 10.125.0.0 255.255.0.0

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

      remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)

      current_peer: x.x.x.x

      #pkts encaps: 11, #pkts encrypt: 11, #pkts digest: 11

      #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9

      #pkts compressed: 0, #pkts decompressed: 0

From above, it shows that the traffic is being encrypted correctly, but for some reason I can't see anything from this side. If I clear the sa associated to my client side public address, the sa doesn't get created if I try to initiate the vpn from my side. It only works from the main side. The other very weird thing is that when the SAs are established, I can ping from 10.1.1.50 with no issues, but the L3 switch cannot ping 10.40.1.40. There is a static route on the L3 switch pointing that subnet to 10.1.1.50, so it seems that nothing past the vpn-main appliance can get to this tunnel. It's very odd...

Thanks!

John

[Jouni Forss · Accepted solution]

Hi,

With regards to the ICMP of the ASA "inside" interfaces, have you used the "management-access " command to enable ICMP or management connections to the interface in question through a VPN connection?

This command is needed to have any chance to ICMP to an ASA interface through a VPN Connection (interface other than the one creating the VPN). To my understanding this can only be configured for one interface so best to check that its not already configured for some other local interface.

Do notice one thing if you are only testing from the actual ASA firewalls. When you issue the "ping" command and specify the interface there (and wont use the closes interface to the destination in this case as the source IP), the ASA wont do any NAT for this ICMP traffics source IP and therefore it wont match the the L2L VPN settings since you have configured NAT for the Remote Sites network. For the Main Site this will work as its supposed to show up with its original IP address and does not depend on a local NAT configuration. Same would go for a basic L2L VPN setup where you configure NAT0 between both local networks.

Its usually best to test the connectivity from the actual hosts.

You could probably also use the "ping tcp" command on the Remote Site ASA since its running newer software and therefore supports this command

ping tcp source 10.20.1.40 12345

Try to generate some TCP SYN packets to some Main Site server IP for a TCP port that you know is listening on. This should both bring the L2L VPN up and confirm connectivity.

You also say that the L2L VPN connection wont form from the Remote Site to the Main Site but when Main Site initiates the connection it works?

Can you provide a "packet-tracer" command output from the Remote Site ASA that should establish the L2L VPN. As this is related to a VPN Connection you should issue the "packet-tracer" command twice since the first one will always fail if the VPN is not up at that moment.

packet-tracer input inside icmp 10.20.1.100 8 0 10.1.1.50

Though its possible that if you have failed to bring up the L2L VPN from the Remote Site and you have only used the ASA CLI that this negotiation has simply failed because of the earlier thing I mentioned about the "ping" command. Specifically that the source address will not get NATed and already because of that will fail to match the L2L VPN configurations.

PS: I kept editing the post while writing and adding parts in between. Hope it makes any sense

- Jouni

[John Blakley]

Jouni,

This is working. Believe it or not, I disabled nat-traversal on my side, but nat-t is enabled on the main side. I'm not sure why this resolved the issue, but everything is working as expected. Cisco TAC looked at it for about an hour this morning too, and they were willing to lab it up because the configs were correct-ish. I don't think any of us (Cisco and I) thought about nat-t. I enabled nat-t yesterday because it was disabled by default.

Thanks for all of your help!

John