How Cisco IOS Unicast NAT works (I)

The emergence of NAT technology stems from the requirements for private network security and the situation that IPv4 addresses are insufficient. Cisco IOS supports the following common NAT technologies. Today, I found that my colleagues in the company do not understand the implementation of Cisco NAT, which leads to configuration problems. Here we will briefly explain the implementation principles of Cisco NAT. Www.2cto.com 1. static NAT. The internal IP address and external IP address correspond one to one. 2. dynamic NAT: one-to-one relationship between the internal IP address and the external IP address. Unlike static NAT, the internal IP address is the corresponding external IP address pool, during each conversion, unused addresses in the external ip address pool are used for translation. 3. overloading NAT, which is a commonly used port address translation, PAT. Multiple internal IP addresses can be mapped to an external IP address through this technology, because a connection consists of the source address, source port, Destination Address, destination port, and protocol. Of course, there are other NAT implementation technologies, but the above three are the most commonly used. These are basic NAT rules. For details, refer to the following document.
Http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml here focuses on the NAT and route table, NAT and ACL and IPSec packet traversal, the packet execution sequence and action. The following table must be kept in mind when understanding NAT and configuring NAT. Generally, the NAT router can translate the source address and destination address. The ip nat inside is on the left, and the ip nat outside is on the right. Of course, NAT can also work on the transport layer or even the application layer on the IP layer, which will be discussed later. Ip nat inside source and ip nat outside source are common configuration commands. The following uses an example to analyze how NAT works. The following work principles must also be kept in mind. When the traffic direction is from outside to inside, the system first searches for and matches the NAT rule for address translation, and then queries the route forwarding table based on the target address. When the traffic direction is from inside to outside, the route forwarding table is first queried based on the target address (if no route is matched, It is discarded ), then, find and match the NAT rule and perform address translation. Www.2cto.com ip nat outside source static
• Translates the source of the IP packets that travel outside to inside. • Translates the destination of the IP packets that travel inside to outside.
 
Ip nat inside source static
• Translates the source of IP packets that travel inside to outside. • Translates the destination of the IP packets that travel outside to inside.
Example topology:
R1 interface Loopback0
Ip address 172.1.1.1 255.255.255.0
!
Interface Ethernet1/0
Ip address 10.1.1.1 255.255.255.0
Duplex half
!
!
Ip classless
Ip route 0.0.0.0 0.0.0.0 10.1.1.2
! R2 interface Ethernet1/0
Ip address 10.1.1.2 255.255.255.0
Ip nat inside
No ip route-cache cef
No ip route-cache
Duplex half
!
Interface Ethernet1/1
Ip address 10.2.2.2 255.255.255.0
Ip nat outside
No ip route-cache cef
No ip route-cache
Duplex half
!
Ip nat inside source static 172.1.1.1 100.1.1.1
Ip nat outside source static 172.3.3.3 100.3.3.3
Ip classless
Www.2cto.com ip route 100.3.3.3 255.255.255.255 10.2.2.3
Ip route 172.1.1.1 255.255.255.255 10.1.1.1 r3!
Interface Loopback0
Ip address 172.3.3.3 255.255.255.0
!
Interface Ethernet1/1
Ip address 10.2.2.3 255.255.255.0
Duplex half
!
Ip classless
Ip route 0.0.0.0 0.0.0.0 10.2.2.2 what we focus on here is the NAT configuration and route configuration of NAT router r2. According to the green rules described above, if you ping the ring port of r3 from the ring port of r1 (ping 100.3.3.3 from 172.1.1.1), 1. ping request is the traffic direction from inside to outside,
2. first, the route table on r2 will be searched for whether there is a route to the destination 100.3.3.3. This is why there is a route to 100.3.3.3 on r2. If there is no route, the router discards the packet and sends the destination unreachable error message. 3. When there is a route match, the system queries whether there are matched NAT rules. If there are any, NAT address translation is performed. There are two NAT rules matching. According to the above conversion principle, the source address is converted to 100.1.1.1, And the destination address is converted to 172.3.3.3. 4. when packets are forwarded to the e1/1 port (ping 172.3.3.3 from 100.1.1.1), when the ring port of r3 receives the ping request (from 100.1.1.1 to 172.3.3.3, ping reply (reply from 172.3.3.3 to 100.1.1.1) to e1/1 port of r2. 1. according to the rule, the traffic direction is from outside to inside. The system first searches for matching NAT rules and performs NAT translation. The two NAT rules match, the converted packet is (reply from 100.3.3.3 to 172.1.1.1), 2. then, the route forwarding table of r2 is queried Based on the destination address after conversion. If there is no route entry to 172.1.1.1, r2 discards the packet and returns the destination unreachable error message, so here we need to configure a route to 172.1.1.1, www.2cto. com3. forward packets to e1/0 ports (reply 172.1.1.1 from 100.3.3.3). The debug conditions on r2 are as follows: r2 # debug ip pac
R2 # debug ip packet
IP packet debugging is on
R2 #
R2 #
R2 # deb
R2 # debug ip na
R2 # debug ip nat
Ip nat debugging is on
R2 # r2 #

From inside to outside: * Sep 30 10:24:12. 019: IP: tableid = 0, s = 172.1.1.1 (Ethernet1/0), d = 100.3.3.3 (Ethernet1/1), routed via FIB
* Sep 30 10:24:12. 019: NAT: s = 172.1.1.1-> 100.1.1.1, d = 100.3.3.3 [10]
* Sep 30 10:24:12. 019: NAT: s = 100.1.1.1, d = 100.3.3.3-> 172.3.3.3 [10]
* Sep 30 10:24:12. 019: IP: s = 100.1.1.1 (Ethernet1/0), d = 172.3.3.3 (Ethernet1/1), g = 10.2.2.3, len 100, forward traffic from outside to inside:
* Sep 30 10:24:12. 127: NAT *: s = 172.3.3.3-> 100.3.3.3, d = 100.1.1.1 [10]
* Sep 30 10:24:12. 127: NAT *: s = 100.3.3.3, d = 100.1.1.1-> 172.1.1.1 [10]
* Sep 30 10:24:12. 127: IP: tableid = 0, s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), routed via FIB
* Sep 30 10:24:12. 127: IP: s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), g = 10.1.1.1, len 100, forwardwww.2cto.com
* Sep 30 10:24:12. 203: IP: tableid = 0, s = 172.1.1.1 (Ethernet1/0), d = 100.3.3.3 (Ethernet1/1), routed via FIB
* Sep 30 10:24:12. 203: NAT: s = 172.1.1.1-> 100.1.1.1, d = 100.3.3.3 [11]
* Sep 30 10:24:12. 203: NAT: s = 100.1.1.1, d = 100.3.3.3-> 172.3.3.3 [11]
* Sep 30 10:24:12. 203: IP: s = 100.1.1.1 (E
R2 # thernet1/0), d = 172.3.3.3 (Ethernet1/1), g = 10.2.2.3, len 100, forward
* Sep 30 10:24:12. 251: NAT *: s = 172.3.3.3-> 100.3.3.3, d = 100.1.1.1 [11]
* Sep 30 10:24:12. 251: NAT *: s = 100.3.3.3, d = 100.1.1.1-> 172.1.1.1 [11]
* Sep 30 10:24:12. 251: IP: tableid = 0, s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), routed via FIB
* Sep 30 10:24:12. 251: IP: s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), g = 10.1.1.1, len 100, forward
* Sep 30 10:24:12. 299: IP: tableid = 0, s = 172.1.1.1 (Ethernet1/0), d = 100.3.3.3 (Ethernet1/1), routed via FIB
* Sep 30 10:24:12. 299: NAT: s = 172.1.1.1-> 100.1.1.1, d = 100.3.3.3 [12]
* Sep 30 10:24:12. 299: NAT: s = 100.1.1.1, d = 100.3.3.3-> 172.3.3.3 [12]
* Sep 30 10:24:12. 299: IP: s = 100.1.1.1 (Ethernet1/0), d = 172.3.3.3 (Ethernet1/1), g = 10.2.2.3, len 100, forward
Www.2cto.com * Sep 30 10:24:12. 347: NAT *: s = 172.3.3.3-> 100.3.3.3, d = 100.1.1.1 [12]
* Sep 30 10:24:12. 347: NAT *: s = 100.3.3.3, d = 100.1.1.1-> 172.1.1.1 [12]
* Sep 30 10:24:12. 347: IP: tableid = 0, s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (
R2 # Ethernet1/0), routed via FIB
* Sep 30 10:24:12. 347: IP: s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), g = 10.1.1.1, len 100, forward
* Sep 30 10:24:12. 407: IP: tableid = 0, s = 172.1.1.1 (Ethernet1/0), d = 100.3.3.3 (Ethernet1/1), routed via FIB
* Sep 30 10:24:12. 407: NAT: s = 172.1.1.1-> 100.1.1.1, d = 100.3.3.3 [13]
* Sep 30 10:24:12. 407: NAT: s = 100.1.1.1, d = 100.3.3.3-> 172.3.3.3 [13]
* Sep 30 10:24:12. 407: IP: s = 100.1.1.1 (Ethernet1/0), d = 172.3.3.3 (Ethernet1/1), g = 10.2.2.3, len 100, forward
* Sep 30 10:24:12. 547: NAT *: s = 172.3.3.3-> 100.3.3.3, d = 100.1.1.1 [13]
* Sep 30 10:24:12. 547: NAT *: s = 100.3.3.3, d = 100.1.1.1-> 172.1.1.1 [13]
* Sep 30 10:24:12. 547: IP: tableid = 0, s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), routed via FIB
* Sep 30 10:24:12. 547: IP: s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), g = 10.1.1.1, len 100, forward
* Sep 30 10:24:12. 595: IP: tableid = 0, s = 172.1.1.1 (Ethernet1/0), d = 100.3.3.3 (Ethernet1/1), routed via FIB
* Sep 30 10:24:12. 595: NAT: s = 172.1.1.1->
R2 #100.1.1.1, d = 100.3.3.3 [14]
* Sep 30 10:24:12. 595: NAT: s = 100.1.1.1, d = 100.3.3.3-> 172.3.3.3 [14]
* Sep 30 10:24:12. 595: IP: s = 100.1.1.1 (Ethernet1/0), d = 172.3.3.3 (Ethernet1/1), g = 10.2.2.3, len 100, forward
* Sep 30 10:24:12. 611: NAT *: s = 172.3.3.3-> 100.3.3.3, d = 100.1.1.1 [14]
* Sep 30 10:24:12. 611: NAT *: s = 100.3.3.3, d = 100.1.1.1-> 172.1.1.1 [14]
* Sep 30 10:24:12. 611: IP: tableid = 0, s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), routed via FIB
* Sep 30 10:24:12. 611: IP: s = 100.3.3.3 (Ethernet1/1), d = 172.1.1.1 (Ethernet1/0), g = 10.1.1.1, len 100, forward! Therefore, when designing NAT, we should consider not only address translation, but also routing! Next, let's look at a more complex situation, that is, when an access control list is configured and an IPSec packet passes through the NAT, the order in which the IPSec packets are processed in the ACL, NAT, and Routing.