NAT configuration

- [Instructor] The fundamentals of how network address translation, or NAT, functions was discussed in the first CCNA course under chapter 11. In essence, NAT remaps one IP address to another by modifying the IP header in packets. This is how private RFC 1918 IPv4 addresses can reach resources on the internet. As an inside host's packet hit the device at the internet border, it will change the private address to be sourced from a publicly routable address and sent on to its destination. As this traffic returns, it will be mapped back to the original sending private address. The first and most common scenario I'm going to cover is port address translation, or NAT overload. This is used in virtually every enterprise to translate many private inside hosts to a single external public IP address. Examine this diagram. I'll translate the inside subnet, 192.168.00/24 to the public address assigned to gig 0/1 on the router. I'll start by telling the router which interfaces are inside and which are outside. Inside will be those inside of my network, while outside will be those facing the LAN. I'll start with the inside interface. Config t, interface gig 0/2, IP NAT inside. Really fairly simple. Now for the outside interface. Interface gig 0/1, IP NAT outside. Now we'll create an access list to specify which traffic should be matched. IP access-list extended, and I'll name it NAT. This creates an extended ACL named NAT. Now, 50 permit IP 192.168.0.0 0.0.0.255 to any destination. I set the sync widths to start at 50 just in case I decide to put some exclusions before this rule. It basically says match 192.168.0.0/24 going anywhere. After the final rule, there's an implicit deny any host to any host, which is exactly what I want. ACLs will be discussed in detail in the next course. Now that I've specified which traffic should be NATted, I can now enter the single statement that will enable translation. IP NAT inside source list NAT interface gig 0/1, and the magic keyword overload. This command says NAT the inside source list of NAT and map those addresses to the IP address assigned to the interface gig 0/1. The addition of the overload keyword enables PAT. Now all of my users heading to the internet should translate successfully. I've sent some random traffic through so I can do verification with show IP NAT translations. This, along with show IP NAT statistics, will show what addresses are being mapped and how many total hits are associated with them. The next most used NAT method is going to be standard static NATting. This maps one private address to another address, which is generally public but doesn't necessarily have to be. I'll modify the diagram by adding an additional subnet that holds servers. I'll statically NAT host 192.168.1.2 over to the 100.65.0.2 address on the LAN. Since my outside interface is already configured, I'll set gig 0/3 to be inside. Config t, interface gig 0/3, IP NAT inside. Static NATs don't require ACLs to be configured. Everything is specified directly on the statement. In this case, it will be IP NAT inside source static 192.168.1.2 over to 100.65.0.2. I've now sent some traffic from server one, and I'll verify it with show IP NAT translations. Another option that is virtually unused but tested over is dynamic NAT with pools. In essence, I configure a pool of inside global addresses, think public IPs, that are available to be assigned dynamically. Now I configure an ACL of inside local addresses, think private IPs, that are allowed to grab IPs from the pool. Then, as a host from the ACL passes through the router, it will be assigned a unique address from the pool and NAT using that combo. As a different host from the ACL then tries to access resources through the router, it will pull a different IP out of the pool. I've modified the diagram again for the new subnet. I'll create a pool that allows 192.168.3.0/24 to dynamically NAT to 100.65.3.0/24. I'll set gig 1/0 to be an inside interface. Config t interface gig 1/0 IP NAT inside. Now I'll create the pool. IP NAT pool, I'll name it greg-pool, 100.65.3.1 to 100.65.3.255 the netmask of 255.255.255.0. The pool command said create a NAT pool and name it greg-pool, then have a starting address of 100.65.3.1 and an ending address of 100.65.3.255. The netmask command will verify if the addressing specified will fit into the subnet of that size, and if it won't, it will reject the command. I'll now create an ACL that will match the server subnet. IP access-list extended greg-NAT. Now I'll add the server range. 50 permit IP 192.168.3.0 0.0.0.255 going to any. Last, I'll add the NAT statement that pools it all together. IP NAT inside source list greg-NAT using pool greg-pool. Again, with NAT being configured on virtually every network in existence, this is an important piece of knowledge to possess.