Question about NAT on ASA (8.4)

Can i apply two nat statements on a ASA? I am trying to setup l2l vpn and apparently i need to "double nat" to prevent the interesting traffic from being natted. I already have my normal nat enabled (nat (inside,outside) dynamic source). DO i have to disable this nat?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

RouteMyPacket

What you mean is that you need to configure your NAT exempt statements so that traffic traversing the L2L will not be Nat'd

i.e.

object network ABC
subnet 192.168.1.0 255.255.255.0

object network XYZ
subnet 192.168.2.0 255.255.255.0

nat (inside,outside) source static ABC ABC destination static XYZ XYZ no-proxy-arp route-lookup

sizeon

I have two NAT statements on my ASA:
1) nat (inside,outside) source static ABC ABC destination static XYZ XYZ no-proxy-arp route-lookup
2) nat (inside,outside) dynamic int

Do i delete the 2nd NAT statement from my ASA?

sizeon

I did more research and think i answered my question. I would only need this statement: nat (inside,outside) source static ABC ABC destination static XYZ XYZ no-proxy-arp route-lookup, correct?

Zartanasaurus

You want "Identity NAT". IOW, you NAT traffic from your VPN source to itself when destined to the VPN destination.

ETA: Yes, your config is right.
ETA2: Make sure your identity NAT config is near the top of the table. It's like how more specific ACL statements go at the top and generic ones go at the bottom. You want to make sure that takes priority over any other statements that would NAT that source traffic to something else.

apr911

Like ACL processing, the ASA processes NAT until it reaches the first match. It stops processing rules after finding a match. On all versions of ASA code, if no match is found, no NAT is used. On 8.3+ the traffic is forwarded as is and on Pre-8.3 code, the traffic may be forwarded or dropped depending on the configuration of nat-control; if nat-control is enabled and no matching nat statement can be found the packet is dropped and a message logged indicating no translation group was found, when nat control is disabled, the packet is forwarded as is.

In the configuration provided by sizeon, the 1st nat, as Zartanasaurus is pointed out, is called an identity NAT. Both the real (the IP actually on the server) and mapped IPs (the IP we are NAT'ing to) are the same. Although often referred to as "nat-exempt" or "no-nat" technically "nat 0" on ASA Pre-8.3 code is identity NAT. If you were to run a "show xlate" command on an Pre-8.3 Firewall, you would see a NAT/xlate statement NAT'ing the real-ip to a mapped-ip that is the same.

Continuing with the first NAT statement provided by sizeon, it is a specifically defined NAT statement (both the specific src/dst parameters are defined for when it is to use the NAT statement) this is called Manual NAT (it is also known a Policy NAT). Manual NAT statements are placed at the top of the NAT table by default. Within the manual NAT section, you can still have a different manual NAT statement that you can match against of higher priority (aka above it) on the NAT table.

The second NAT statement is a Dynamic NAT. As you are not defining all of the parameters, the ASA automatically chooses when to use this NAT statement. This is known as Auto-NAT. Auto-NAT statements appear 2nd on the NAT table. Just like with manual NAT's it is possible to have match against a higher priority Auto-NAT statement on the NAT table.

There is a 3rd and final section on the NAT table called Manual-After-Auto-Nat. This isnt used frequently but as the name implies it allow you to create specific "manual NATs" of a very low priority that are only applied after finding no matching Manual or Auto NAT statement. Here is a use case that I came up with...
Parameters:
1. I want my servers in my DMZ to use their own Auto-NAT public IP whenever possible.
2. I have servers in my DMZ that do not have a public IP.
3. I want my servers in my DMZ without a public IP to be able to reach a specific public resource (or set of resources). Lets say google dns at 8.8.8.8
4. I want my servers in my DMZ without a public IP to be able to transmit through the firewall as themselves whenever trying to reach another resource (in other words, we cant NAT all unmatched traffic out of the DMZ and then use ACLs to prevent them from reaching other public resources).
5. I dont want to have to manage an object list of DMZ servers that dont have their own public IP

I can enter the following NAT statement:

nat (dmz,outside) after-auto source dynamic DMZ_NET PUBLIC_IP_PAT destination static 8.8.8.8 8.8.8.8

Once again, it is possible to have match against a higher priority manual-after-auto-NAT statement on the NAT table.

Thankfully unlike reordering NAT statements in Pre-8.3 code which required you to remove all matching NAT statements and then re-enter them in the order you want them to appear, in 8.3+ you can specify at what position you want that NAT statement to in its respective section (Manual, Auto, Manual-After-Auto) similar to the way you can add ACLs at specific line numbers.

sizeon wrote: »

I have two NAT statements on my ASA:
1) nat (inside,outside) source static ABC ABC destination static XYZ XYZ no-proxy-arp route-lookup
2) nat (inside,outside) dynamic int

Do i delete the 2nd NAT statement from my ASA?

sizeon wrote: »

I did more research and think i answered my question. I would only need this statement: nat (inside,outside) source static ABC ABC destination static XYZ XYZ no-proxy-arp route-lookup, correct?

Your first configuration with 2 NAT statements is correct. The first NAT statment says to NAT Real-IP ABC to a Mapped-IP that is also ABC but to do this only when the destination is XYZ. Since we dont want to change the destination, we tell it to also identity NAT the destination address to XYZ.

As configured here is what happens with NAT:

INSIDE - SRC ABC DST XYZ - Finds manual NAT match Becomes:
OUTSIDE- SRC ABC DST XYZ - Packet matches a crypto-acl/interesting traffic.
Packet is sent out the OUTSIDE interface encrypted over the VPN to remote host XYZ

INSIDE - SRC ABC DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC ABC DST 8.8.8.8 - Finds AutoNat match on "nat (insdide,outside) dynamic int" Becomes:
OUTSIDE- SRC INT DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is PAT'd as INT and sent out the OUTSIDE interface unencrypted to internet host 8.8.8.8

INSIDE - SRC DEF DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC DEF DST 8.8.8.8 - Finds AutoNat match on "nat (insdide,outside) dynamic int" Becomes:
OUTSIDE- SRC INT DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is PAT'd as INT and sent out the OUTSIDE interface unencrypted to internet host 8.8.8.8

If you delete the 1st NAT statement then your hosts will all match the autonat statment and NAT to the firewall's interface IP on the outside. Since NAT is applied, the traffic will not match the crypto-acl/interesting traffic and will not be sent across the VPN.

Without NAT statement 1 here is what happens with NAT:

INSIDE - SRC ABC DST XYZ - No manual NAT Match found. Moves to AutoNAT List
INSIDE - SRC ABC DST XYZ - Finds AutoNat match on "nat (insdide,outside) dynamic int" Becomes:
OUTSIDE- SRC INT DST XYZ - Packet does not match a crypto-acl/interesting traffic
Packet is PAT'd and sent out the OUTSIDE interface unencrypted to host XYZ via default gateway.
If XYZ is a private IP it is likely black holed or returned as no route to host.
If XYZ is public this is likely denied by remote side firewall as your INT IP is not whitelisted and the traffic was not over VPN.

INSIDE - SRC ABC DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC ABC DST 8.8.8.8 - Finds AutoNat match on "nat (insdide,outside) dynamic int" Becomes:
OUTSIDE- SRC INT DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is PAT'd as INT sent out the OUTSIDE interface unencrypted to internet host 8.8.8.8

INSIDE - SRC DEF DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC DEF DST 8.8.8.8 - Finds AutoNat match on "nat (insdide,outside) dynamic int" Becomes:
OUTSIDE- SRC INT DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is PAT'd as INT and sent out the OUTSIDE interface unencrypted to internet host 8.8.8.8

If you delete the 2nd NAT statment then your hosts on the inside network will not be able to reach resources on the outside segement that do not have a route back to the REAL IP of the host on the inside.

Given the names of your segments and the VPN connection on the outside, Im assuming your outside segment is public facing and your inside segment is private RFC-1918 addresses. This means your hosts will not be able to reach anything in the internet if you remove the 2nd NAT statement.

Without NAT Statement 2 here is what happens with NAT:

INSIDE - SRC ABC DST XYZ - Finds manual NAT match Becomes:
OUTSIDE- SRC ABC DST XYZ - Packet matches a crypto-acl/interesting traffic.
Packet is sent out the OUTSIDE interface encrypted over the VPN to remote host XYZ

INSIDE - SRC ABC DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC ABC DST 8.8.8.8 - No AutoNat match found. Moves to Manual-After-AutoNat list
INSIDE - SRC ABC DST 8.8.8.8 - No Manual-After-Autonat match found. No NAT applied.
OUTSIDE- SRC ABC DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is sent out the OUTSIDE interface as ABC unencrypted to internet host 8.8.8.8

If ABC is a private IP this traffic is likely blackholed by your ISP, even if its not and the packet manages to get to 8.8.8.8, Google DNS will not have a return route to your Private IP space and thus will be unable to respond.

If ABC is public, this would work however, you are using the real IP, not the desired PAT and if 8.8.8.8 had an ACL whitelisting only the source IP INT you would not match the ACL and be dropped. Additionally, regardless of PAT address whitelisting, any host on the INSIDE segment without a public IP would not have a public PAT address

INSIDE - SRC DEF DST 8.8.8.8 - No manual NAT match found. Moves to AutoNAT List
INSIDE - SRC DEF DST 8.8.8.8 - No AutoNat match found. Moves to Manual-After-AutoNat list
INSIDE - SRC DEF DST 8.8.8.8 - No Manual-After-Autonat match found. No NAT applied.
OUTSIDE- SRC DEF DST 8.8.8.8 - Packet does not match a crypto-acl/interesting traffic
Packet is sent out the OUTSIDE interface as DEF unencrypted to internet host 8.8.8.8

If DEF is a private IP this traffic is likely blackholed by your ISP, even if its not and the packet manages to get to 8.8.8.8, Google DNS will not have a return route to your Private IP space and thus will be unable to respond.

If DEF is public, this would work however, you are using the real IP, not the desired PAT and if 8.8.8.8 had an ACL whitelisting only the source IP INT you would not match the ACL and be dropped. Additionally, regardless of PAT address whitelisting, any host on the INSIDE segment without a public IP would not have a public PAT address

Finally, all that being said, the no-proxy-arp and the route-lookup directives attached to your manual-nat are not strictly required.

While I am a proponent of disabling proxy-arp of firewalls running 8.3+, especially on publicly facing interfaces (see https://www.fir3net.com/Firewalls/Cisco/cisco-asa-proxy-arp-gotcha.html for why), I much prefer turning it off globally for the outside interface using "sysopt noproxyarp outside" as opposed to a piecemeal NAT statement by statement approach. It resolves the issue of what happens if you one day forget to apply the no-proxy-arp directive.

As for the route-lookup command... This is used to force the ASA to ignore the egress interface defined in the NAT statement (outside in this case) and use the interface that matches the route (which I assume is also outside). Basically you are making the ASA look at the routing table twice now... Once to determine the egress interface and once to determine the route to take. Since the egress interface in the NAT Statement matches that of the route, this first lookup is unnecessary. You can leave off the "route-lookup" directive, the ASA will use the NAT defined egrees interface of "outside" and then look at the routing table to determine its next hop.

I hope this post proves edcuational and doesnt confuse you further. Im happy to answer any questions you may have.