ASA 9.1X - NAT0

[ciscotech45]

I have a question on how the NAT0 (nat bypass) statements would look like for an ASA 9.1x code. I am now running 8.0.2. Here is how the relevant parts of the config  looks like: (certain information have been modified)

interface GigabitEthernet0/0

no nameif

no security-level

no ip address

interface GigabitEthernet0/0.10

vlan 10

nameif outside

security-level 0

ip address 201.102.10.1 255.255.255.0

interface GigabitEthernet0/0.20

vlan 20

nameif link20

security-level 20

ip address 192.168.2.0 255.255.255.0

interface GigabitEthernet0/1

no nameif

no security-level

no ip address

interface GigabitEthernet0/1.30

vlan 30

nameif link30

security-level 100

ip address 192.168.3.0 255.255.255.0

interface GigabitEthernet0/1.40

vlan 40

nameif inside

security-level 100

ip address 192.168.4.0 255.255.255.0

object network remote-nets

subnet 10.8.0.0 255.255.0.0

subnet 10.7.0.0 255.255.0.0

subnet 10.6.0.0 255.255.0.0

object network corp-nets

subnet 192.168.2.0 255.255.255.0

subnet 192.168.3.0 255.255.255.0

subnet 192.168.4.0 255.255.255.0

The objective is so that all the different  VLANs above can connect to the remote networks defined in object group 'remote-nets' via a site to site vpn tunnel.No NATing is required via this tunnel.For this with the 8.0.2 code, here is what I had as the NAT0 statement:

access-list inside_nat0_outbound extended permit ip object-group corp-nets object-group remote-nets

and here is the crypto ACL for the site to site VPN:

access-list corp-remote extended permit ip object-group corp-nets object-group remote-nets

Now my question is, with the new 9.1x code, is there any way I can have one single nat0 statement like I had before? Below is what I was thinking of, but I am sure one alone won't be  enough. Can someone please confirm? what all such statements would I need?

nat (inside,outside) source static corp-nets corp-nets destination static remote-nets remote-nets

And lastly, as far as the vpn tunnel config is concerned is there anything else (like the NAT differences) that is different in 9.1x that I need to watch out for?

Thanks!!

[Jouni Forss]

Hi,

The configuration format you mention in the above post is the correct one. You can use the same "object-group" in the actual "nat" command.

You are essentially telling the ASA that traffic between these networks will not be NATed.

With regards to the VPN configurations there are minor command format changes compared to older softwares. This mostly includes a separate "ikev1" parameter inserted into a configurations.

ISAKMP Policys are for example configured with "crypto ikev1 policy 10" for example or the Pre Shared Key under the "tunnel-group" would be configured with "ikev1 pre-shared-key" and so on.

There is no real difference with regards to NAT and VPN (other than the NAT configuration format). NAT is still performed before any VPN negotiation takes place so the translated source and untranslated destination is use to match the Crypto ACL you might be using for L2L VPN.

Hope this helps

- Jouni

[ciscotech45]

hi, thanks for your reply.

In the config that I posted above, can I have just one NAT statement like the one below, which will make sure that anything going from corps-net to remote-nets will not get NATed? (even though the subnets in corps-net are associated with different interfaces)

nat (any,outside) source static corp-nets corp-nets destination static remote-nets remote-nets

thank you.

[Jouni Forss · Accepted solution]

Hi,

If your networks are behind different interfaces then you would have to use the "any" interface like above to let the ASA determine the correct interface for each network according to the routing table rather than the NAT command itself.

I only tend to use this (any) with the Dynamic PAT configuration for all the LAN and DMZ networks behind the firewalls I manage.

I would imagine this should work.

If the situation was so that you actually needed to NAT either destination or source network then you would always have to make sure that the "object-group" contained the real and mapped networks in the correct order or they would match in the wrong way naturally.

- Jouni