Meraki to ASA site-to-site setup - what is the purpose of disabling NAT on the remote peer?

Solved
SmokinIndo
Comes here often

Meraki to ASA site-to-site setup - what is the purpose of disabling NAT on the remote peer?

I'm specifically referring to step 4 in the CLI instructions for setting up the ASA side of a site-to-site tunnel. I would post a link to the official Meraki documentation, but the forum doesn't allow links, so it is what it is. Step 4 of the instructions say:

 

4.     Exclude the VPN traffic from being natted

nat 0 access-list 90 

 

The network we're trying to build a tunnel to uses NAT for all the VMs on our network. Wouldn't disabling NAT make it so that no outside devices are able to communicate with machines on our network? 

 

Why do I want to disable NAT for the access-list that I'm using to set up a tunnel?

1 Accepted Solution
GIdenJoe
Kind of a big deal
Kind of a big deal

The documentation on that part is OLD....

The ASA doesn't use the nat 0 syntax anymore since two years or more.

 

To explain why you need to disable nat for ipsec traffic.

 

On an ASA you configure NAT in network objects which is called AutoNAT and goes into section 2.

You also have manual NAT rules that go into section 1 (before AutoNAT) and section 3 (after AutoNAT).

So the NAT rules are processed just like firewall rules.  First match is used as rule.

 

In both Auto and Manual NAT rules you have to specify the incoming and outgoing interface and the inverse rule is implicitly made.

 

This part is the most important part so pay attention to this:
In most cases you would use AutoNAT which uses a network object.
So you would define one of your inside networks in a network object and then inside that object say nat(inside,outside)dynamic interface.
That means if traffic coming FROM the matching subnet into the INSIDE interface and leaving the OUTSIDE interface it will get a dynamic PAT to the interface IP.

This means that ALL traffic would be translated.  Also the IPsec traffic that happens to also leave through the outside interface.  So you would send all your packets to the network on the other side of the IPsec tunnel but change the source IP to the outside interface IP.  As a consequence, return traffic would not be sent back inside the tunnel and dropped at the ASA because of a lacking session.

 

So you need to make a manual NAT rule in section 1 that will take precedence over the AutoNAT rule that says for traffic coming from source network to destination network, inside interface to outside interface do not NAT.

So that one is matched first and traffic will not be natted.

View solution in original post

6 Replies 6
CarolineS
Community Manager
Community Manager

Hi @SmokinIndo!

 

Thanks for posting - this post will get more of the right eyeballs in the main Meraki forums (this forum is specific to Meraki Go). I'm going to move it over.

 

Cheers!

Caroline S | Community Manager, Cisco Meraki
New to the community? Get started here
PhilipDAth
Kind of a big deal
Kind of a big deal

This is the guide you are referring to:

https://documentation.meraki.com/MX/Site-to-site_VPN/MX_to_Cisco_ASA_Site-to-site_VPN_Setup 

 

What that does is say don't use NAT for packets going over the VPN.  It won't have any impact on any other traffic.

GIdenJoe
Kind of a big deal
Kind of a big deal

The documentation on that part is OLD....

The ASA doesn't use the nat 0 syntax anymore since two years or more.

 

To explain why you need to disable nat for ipsec traffic.

 

On an ASA you configure NAT in network objects which is called AutoNAT and goes into section 2.

You also have manual NAT rules that go into section 1 (before AutoNAT) and section 3 (after AutoNAT).

So the NAT rules are processed just like firewall rules.  First match is used as rule.

 

In both Auto and Manual NAT rules you have to specify the incoming and outgoing interface and the inverse rule is implicitly made.

 

This part is the most important part so pay attention to this:
In most cases you would use AutoNAT which uses a network object.
So you would define one of your inside networks in a network object and then inside that object say nat(inside,outside)dynamic interface.
That means if traffic coming FROM the matching subnet into the INSIDE interface and leaving the OUTSIDE interface it will get a dynamic PAT to the interface IP.

This means that ALL traffic would be translated.  Also the IPsec traffic that happens to also leave through the outside interface.  So you would send all your packets to the network on the other side of the IPsec tunnel but change the source IP to the outside interface IP.  As a consequence, return traffic would not be sent back inside the tunnel and dropped at the ASA because of a lacking session.

 

So you need to make a manual NAT rule in section 1 that will take precedence over the AutoNAT rule that says for traffic coming from source network to destination network, inside interface to outside interface do not NAT.

So that one is matched first and traffic will not be natted.

SmokinIndo
Comes here often

Thank you for your response. Shouldn't the NAT exception apply to phase one traffic as well? Our phase one vpn traffic appears to be running fine. It's entering phase 2 that it seems to be having trouble. I'm trying to troubleshoot it as the lifetimes, encryption, and hash all match up. I was wondering if the NAT instruction was causing the issue.

CptnCrnch
Kind of a big deal
Kind of a big deal

NAT will come into place only for „live“ traffic, not VPN establishment.

GIdenJoe
Kind of a big deal
Kind of a big deal

The whole NAT explanation I did has nothing to do with the IKE negotiations.

The NAT exemption by using "identity NAT" which means disabling NAT has rammifications for traffic passed through an already established working phase 2 SA.

 

IKE phase 1 negotiations do include NAT-T and NAT-D negotiations but those are necessary if there is another NAT device in front of your ASA or MX.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels