NAT: IPsec DMVPN and Internet Access – Review NAT Deployment scenarios

This post describes different deployment scenarios where Network Address Translation (NAT) is implemented with IPsec DMVPN.

Contents

• Network Topology
• Network Address Translation (NAT) Overview
• What is Inside and Outside?
• NAT and Routing – Order of Operations
• Initial Configuration
• Scenario 1 – PAT, IPsec DMVPN and Internet Access
• Scenario 2 – Basic Static NAT Translation
• Scenario 3 – Server TCP Load Balancing
• Scenario 4 – Route-map Reversible
• Scenario 5 – Static Policy NAT
• Scenario 6 – Outside NAT and Add-route
• Scenario 7 – Static Extendable NAT and IP Aliasing
• References

Network Topology

Figure 1

Network Address Translation (NAT) Overview

Network Address Translation (NAT) translates non-routable private IP addresses to routable public IP addresses from a pool of public IP addresses that have been designated for NAT. This enables to conserve on the number of public IP addresses and implicitly enforces security hiding private IP addresses. NAT can also resolve overlapping subnet issues and it is widely deployed to connect devices to the Internet.

What is Inside and Outside?

Inside or Outside NAT addresses depend on where the device doing the translation is located in the network. It is easier to use an example in order to understand this terminology.

Figure 2

Figure 2 shows R1 is configured to be the Translator in the network and from its perspective we analyze a Ping from R11 to 2.2.2.10. The traffic flow is originated by R11’s eth0/0 IP address, 10.10.1.11. 10.10.1.11 is the Inside local IP address; private IP address before translation occurs. R1 translates the Inside local to an Inside global IP address from the NAT Pool. In this case the first available IP address is 1.1.1.10. 1.1.1.10 is the Inside public and routable IP address after translation. R2 receives the Ping because 2.2.2.10 is part of its local NAT Pool of public IP addresses. 2.2.2.10 is called Outside global IP address from R1’s perspective. R2 checks its NAT Translation database and finds out there is an entry that correlates 2.2.2.10 to R22’s eth0/0 IP address, 10.10.2.22. Therefore, R2 modifies the destination of the packet to be 10.10.2.22 and forwards the packet to the final destination. 10.10.2.22 is the Outside local IP address; a private external IP address after translation. In this scenario we have what is called double NAT (R1 and R2 are configured for NAT).

However, if the ping from R11 were destined to Server1 in the topology, Outside global and Outside local would have been the same IP address, 11.11.11.1. This is because Server1 is not doing NAT or it is not behind a device doing NAT. Inside local: 10.10.1.11, Inside global: 1.1.1.10 (or any other IP from R1’s NAT Pool), Outside global: 11.11.11.1 and Outside local: 11.11.11.1.

Figure 3 shows the same topology but in this case R2 is the Translator because the Ping is originated by R22 and destined to 1.1.1.11. The Inside local IP address is now R22’s eth0/0 IP address, 10.10.2.22, which is translated to an Inside global IP address from R2’s NAT Pool, for example, 2.2.2.11. R1 receives the Ping to 1.1.1.11, the Outside global, because it is part of its NAT Pool that is finally translated to the Outside local 10.10.1.11.

Figure 3

Note that in both scenarios the Ping is destined to an Outside global IP address because they are public and routable. It is not possible to ping directly to an Outside local IP address with double NAT configured because Outside local IP addresses are private and not routable. This is different when we ping Server1 because translation only happens once and Outside global and Outside local are the same public and routable IP address (11.11.11.1).

NAT and Routing – Order of Operations

On the Inside zone: Packets are first routed and then translated.

R1 in Figure 2 checks its routing table for the destination 2.2.2.10. R1 sees it needs to send the packet through eth0/1 to reach the destination, which happens to be configured for NAT. Once R1 knows the route to the destination it translates 10.10.1.11 to 1.1.1.10.

On the Outside zone: Packets are first translated and then routed which allows routing for returning packets with translated sources.

R2 receives the ping from R1. R2 sees the destination 2.2.2.10 is part of its NAT pool and needs to do the translation first in order to find out the final internal destination. 2.2.2.10 is translated to 10.10.2.22. R2 queries the routing table for destination 10.10.2.22 and finds out it needs to forward the packet through its eth0/0 interface.

Note- for NAT Virtual Interface (NVI) translation rules (NAT) are applied always after the route decision for Inside and Outside zones.

Initial Configuration

Figure 4

This is the initial configuration for Routing, Dynamic Multipoint VPN (DMVPN) and Internet Protocol Security (IPsec) Encapsulating Security Payload (ESP).

R1 Configuration:

R2 Configuration:

The output of these show commands verifies the DMVPN tunnel is established and crypto has been successfully negotiated.

Traffic from R22 to R11 is going through Tunnel0:

Scenario 1 – PAT, IPsec DMVPN and Internet Access

Figure 5

R1 and R2 instead of defining a NAT Pool in this example, they have been configured to use Port Address Translation (PAT). This means they are using their eth0/1 IP address (outside NAT interface) and Port information to do NAT. In addition the Access List (ACL) ANY_SOURCE defines what Inside local traffic is going to be translated (any traffic going to any destination in the configuration below).

Ping to Server1

Once NAT is configured on R1 and R2, R11 pings Server 1. This is shown in Figure 6.

Figure 6

We verify that R1 translates the source, Inside local, to Inside global and is using port information.

DMVPN establishment failure

However, we can see R1 and R2 are getting some syslog messages saying that IPsec negotiation cannot be completed.

R2, the DMVPN Spoke who triggers the DMPVN and implicitly the IPsec negotiation, shows the Crypto Security Association (SA) as MM_NO_STATE instead of QM_IDLE and the DMVPN State as IKE instead of UP. This means there is a problem with Crypto negotiation between the endpoints (R1 and R2).

The translation rule defined (ip nat inside source list ANY_SOURCE interface Ethernet0/1 overload) is a dynamic NAT rule (static keyword is not configured) which means that traffic that has not been originated from the Inside to begin with it is going to be blocked from the Outside. Only returning packets with translated sources are allowed.

In our example R2 is the DMVPN Spoke and is who is going to trigger the IPsec/DMVPN negotiation with R1. R1 is the DMVPN Hub and only listens to incoming requests in order to form the encrypted tunnel. The problem here is there is no a translation entry in R1’s NAT table for this traffic originated from the Inside therefore the IPsec negotiation originated from R2 is going to be blocked.

It is a security measure because if everything is being translated, this means the packets dropped are unsolicited packets. In this example this is not only affecting the data plane, it is also affecting the control plane.

The solution is to bypass NAT for Crypto Protocols (isakmp and IPSec ESP). It is necessary to be more specific when we define the ACL to allow the crypto negotiation to happen and then the DMVPN establishment.

Figure 7

Bypass NAT for any Crypto negotiation traffic means when R2 (222.222.222.222) presents its isakmp and IPsec proposals to R1 (111.111.111.111) R1 does not check its Translation database because this traffic is exempted from NAT. As long as peer addresses (111.111.111.111 and 222.222.222.222) are reachable the negotiation happens as normal. In our topology the peer addresses are reachable via BGP.

Therefore, this configuration on R1/R2 does not mean filter the traffic (deny), it means do not perform translation and route as normal (as NAT was never configured).

For more information about DMPVN configuration check Dynamic Multipoint VPN (DMVPN) and IGP Routing Protocols.

For more information about Crypto configuration (isakmp and IPsec) check IPsec: Crypto Maps, GRE and VTI.

Scenario 2 – Basic Static NAT Translation

The difference between Static and Dynamic NAT is Static NAT is reversible; it allows Inside to Outside but also Outside to Inside translation. Dynamic NAT, however, only allows Inside to Outside and the return translation  as we saw in our previous example.

This configuration is useful when we want to allow access to Internal Public Services such as Email or Web Applications.

Figure 8

We configure R11 as HTTP Server.

Now we configure on R1 a static NAT translation that allows external TCP connections to R1’s eth0/1 IP Address 1.1.1.1 on Port 8080 to be forwarded to R11’s eth0/0 IP address 10.10.1.11 on Port 80. Notice that the ports do not have to be equal, which can help to hide the real ports used for security reasons (bypass port scanners on well known ports such as HTTP – TCP 80).

We can see the new entry in the Translation table.

It is possible to Load Balance (Round Robin method) using NAT incoming connections to a pool of servers in the Inside network.

Figure 9

Allocation is done on a round-robin basis and only when a new connection is opened from the Outside to the Inside network. Non-TCP traffic is passed untranslated (unless other translations are configured).

A rotary pool of sequential IP addresses is defined as a NAT Pool of Internal Servers.  Then Destination addresses that match the access list INSIDE_GLOBAL are replaced with addresses from the rotary pool.

R1 Configuration:

To verify the configuration we telnet from Server1 to R1’s Inside Global IP address several times. We can see every time we telnet we connect to a different Internal router.

Scenario 4 – Route-map Reversible

There is a common misunderstanding of using the reversible option for NAT with route-maps configuration. A priori it seems to be the solution to be able to initiate a connection from the Outside to the Inside Global dynamically. However, as we will see, we still need the connection to be originated from the Inside first in order to accept future connections originated from the Outside.

On R1 we configure that traffic originated from R11’s eth0/0 IP address to Server1 is going to be translated to an Inside Global IP address from the pool 1.1.1.10 – 1.1.1.20.

We verify our configuration with a Ping from R11 to Server1 (11.11.11.1) and we check the translation has occurred.

Verification:

Note that only a particular entry for the flow of Ping packets was created here. This happens for all flows initiated from Inside. The entry would be so specific on the transport protocol, addresses and ports that it would be impossible to initiate a new flow from Outside and have it delivered to the Inside device because it would not match any entry in the NAT translation table.

Now let’s add the reversible keyword and see what happens.

Figure 10

Now we Ping from Outside, Server1, to the Inside Global IP address 1.1.1.11 (the next available IP address from the INSIDE_GLOBAL pool). We can see this traffic is being blocked, therefore even with reversible option configured, traffic from the Outside to the Inside is not allowed.

We now initiate the Ping from R11 instead. We can see in the output below that the Ping is successful.

If we check the NAT table we note that there are now two entries. The first one is specific to the flow, however, the second entry simply puts the Inside local and the Inside global addresses into mutual correspondence. Now, if somebody from Outside initiates a connection to the address 1.1.1.11 (the Inside global in this case), it will be translated back to  10.10.1.11 thanks to this “template” entry that is not specific to any flow, just to the two corresponding addresses.

Moreover, this entry does not expire. After a while if we show the translations we can see this entry is still there whereas the more specific has expired.

So after the first packet went from Inside to Outside, the router with the reversible keyword (R1 in our topology) created a mapping and entered this template entry into the NAT translation table so that for the future, a traffic from Outside can come in and be forwarded to the Inside device. This traffic does not need to be the same traffic that was originated from the Inside (a Ping in our example), it could be any traffic (for example a Telnet).

Scenario 5 – Static Policy NAT

Static policy NAT (static NAT with route-maps) allows the use of mappings to different Inside global IP addresses for the same Inside local IP address. The route-maps are used to classify what traffic is used with what NAT translation rule. This configuration is commonly used on multi-homed routers out to multiple Internet Service Providers (ISPs).

Figure 11

In our example, we want to use different Outside global IP addresses depending on the type of traffic, Telnet or HTTP, that is originated from Server1 and going to R11.

This is R1 Configuration:

The output below verifies the Inside global IP address used is different depending on the traffic.

Outside NAT translates the source address of the IP packets that travel from Outside of the network to Inside the network. This action translates the destination address of the IP packets that travel in the opposite direction, from Inside to Outside the network. This command is useful in situations such as overlapping networks, where the Inside network addresses overlap addresses that are Outside the network.

Figure 12 shows the NAT translation process in 4 steps when Outside NAT is configured on R1.

Figure 12

R1 configuration:

When Server1 (11.11.11.1) does a Telnet to R11’s eth0/0 IP address (10.10.1.11 – Inside local IP address), R1 checks its NAT pool and chooses the first IP available (20.20.20.1). R1 changes the source of the packet to this IP address and forwards it to R11.  R11 replies to 20.20.20.1 and the packet is received by R1. R1 translates it to 11.11.11.1 according to the Translation table and forwards the packet to Server1.

However, as we mentioned before when R1 does the NAT from Inside to Outside remember that R1 does routing first and once the output interface is selected as part of the routing decision checks if NAT is configured. NAT is configured on R1’s eth0/1 so R1 checks its Translation table and changes the destination of the packet to 11.11.11.1.

Everything works fine because R1 has a default route.

What would happen if we remove the static default route and we define a more specific route to reach Server1?

Now when R1 tries to route traffic to 20.20.20.1 sees there is no route to the destination.

R1 does not have a route to 20.20.20.1 or default route anymore so the retuning traffic is dropped and the Telnet does not work.

This is what the add-route option tries to solve. It adds a route to the Outside local destination. It is a /32 route used for routing and translating packets that travel from Inside to Outside the network.

We verify the result:

The output shows a /32 route for the Outside Local address 20.20.20.1, which is created due to the add-route option of the ip nat outside source command.

To allow static NAT mappings of one Inside local address to multiple Inside global addresses, the keyword extendable is added to the end of the mapping statements.

The configuration below is not allowed by default.

We need to add the extendable option.

This is the final result:

In addition, the router doing NAT keeps record of the Outside global IP addresses by default. The purpose of this alias is so that it will respond to ARP requests sent to the router for the Outside global IP address.

We can disable this behavior with the no-alias option.

References

http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=4

https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13770-1.html