Friday 3 August 2018

CONFIGURE NAT

NAT
Network Address Translation
Network Address Translation (NAT) and how to configure the firewall for NAT.
NAT allows you to translate private, non-routable IPv4 addresses to one or more globally-routable IPv4
addresses, thereby conserving an organization’s routable IP addresses. NAT allows you to not disclose
the real IP addresses of hosts that need access to public addresses and to manage traffic by performing
port forwarding. You can use NAT to solve network design challenges, enabling networks with identical IP
subnets to communicate with each other. The firewall supports NAT on Layer 3 and virtual wire interfaces.
The NAT64 option translates between IPv6 and IPv4 addresses, providing connectivity between networks
using disparate IP addressing schemes, and therefore a migration path to IPv6 addressing. IPv6-to-IPv6
Network Prefix Translation (NPTv6) translates one IPv6 prefix to another IPv6 prefix. PAN-OS supports all
of these functions.
If you use private IP addresses within your internal networks, you must use NAT to translate the private
addresses to public addresses that can be routed on external networks. In PAN-OS, you create NAT policy
rules that instruct the firewall which packet addresses and ports need translation and what the translated
addresses and ports are.

• NAT Policy Rules
• Source NAT and Destination NAT
• NAT Rule Capacities
• Dynamic IP and Port NAT Oversubscription
• Dataplane NAT Memory Statistics
• Configure NAT
• NAT Configuration Examples

Source NAT
Source NAT is typically used by internal users to access the Internet; the source address is translated and thereby kept private. There are three types of source NAT:
·         Dynamic IP and Port (DIPP)—Allows multiple hosts to have their source IP addresses translated to the same public IP address with different port numbers. The dynamic translation is to the next available address in the NAT address pool, which you configure as a Translated Address pool be to an IP address, range of addresses, a subnet, or a combination of these.
As an alternative to using the next address in the NAT address pool, DIPP allows you to specify the address of the Interface itself. The advantage of specifying the interface in the NAT rule is that the NAT rule will be automatically updated to use any address subsequently acquired by the interface. DIPP is sometimes referred to as interface-based NAT or network address port translation (NAPT).
DIPP has a default NAT oversubscription rate, which is the number of times that the same translated IP address and port pair can be used concurrently. For more information, see Dynamic IP and Port NAT Oversubscription and Modify the Oversubscription Rate for DIPP NAT .
·         Dynamic IP—Allows the one-to-one, dynamic translation of a source IP address only (no port number) to the next available address in the NAT address pool. The size of the NAT pool should be equal to the number of internal hosts that require address translations. By default, if the source address pool is larger than the NAT address pool and eventually all of the NAT addresses are allocated, new connections that need address translation are dropped. To override this default behavior, use Advanced (Dynamic IP/Port Fallback) to enable use of DIPP addresses when necessary. In either event, as sessions terminate and the addresses in the pool become available, they can be allocated to translate new connections.
Dynamic IP NAT supports the option for you to Reserve Dynamic IP NAT Addresses .
·         Static IP—Allows the 1-to-1, static translation of a source IP address, but leaves the source port unchanged. A common scenario for a static IP translation is an internal server that must be available to the Internet.
Destination NAT
Destination NAT is performed on incoming packets, when the firewall translates a public destination address to a private address. Destination NAT also offers the option to perform port forwarding or port translation.
Destination NAT is a one-to-one, static translation that you can configure in several formats. You can specify that the original packet have a single destination IP address, a range of IP addresses, or a list of single IP addresses, as long as the translated packet is in the same format and specifies the same number of IP addresses. The firewall statically translates an original destination address to the same translated destination address each time. That is, if there is more than one destination address, the firewall translates the first destination address configured for the original packet to the first destination address configured for the translated packet, and translates the second original destination address configured to the second translated destination address configured, and so on, always using the same translation.
For example, the firewall allows the following destination NAT translations:
One common use of destination NAT is to configure several NAT rules that map a single public destination address to several private destination host addresses assigned to servers or services. In this case, the destination port numbers are used to identify the destination hosts. For example:
·         Port Forwarding—Can translate a public destination address and port number to a private destination address, but keeps the same port number.
·         Port Translation—Can translate a public destination address and port number to a private destination address and a different port number, thus keeping the real port number private. It is configured by entering a Translated Porton the Translated Packet tab in the NAT policy rule. See the Destination NAT with Port Translation Example .
Dynamic IP and Port NAT Oversubscription
Dynamic IP and Port (DIPP) NAT allows you to use each translated IP address and port pair multiple times (8, 4, or 2 times) in concurrent sessions. This reusability of an IP address and port (known as oversubscription) provides scalability for customers who have too few public IP addresses. The design is based on the assumption that hosts are connecting to different destinations, therefore sessions can be uniquely identified and collisions are unlikely. The oversubscription rate in effect multiplies the original size of the address/port pool to 8, 4, or 2 times the size. For example, the default limit of 64K concurrent sessions allowed, when multiplied by an oversubscription rate of 8, results in 512K concurrent sessions allowed.
The oversubscription rates that are allowed vary based on the model. The oversubscription rate is global; it applies to the firewall. This oversubscription rate is set by default and consumes memory, even if you have enough public IP addresses available to make oversubscription unnecessary. You can reduce the rate from the default setting to a lower setting or even 1 (which means no oversubscription). By configuring a reduced rate, you decrease the number of source device translations possible, but increase the DIP and DIPP NAT rule capacities. To change the default rate, see Modify the Oversubscription Rate for DIPP NAT .
If you select Platform Default, your explicit configuration of oversubscription is turned off and the default oversubscription rate for the model applies, as shown in the table below. The Platform Default setting allows for an upgrade or downgrade of a software release.
The following table lists the default (highest) oversubscription rate for each model.
The firewall supports a maximum of 256 translated IP addresses per NAT rule, and each model supports a maximum number of translated IP addresses (for all NAT rules combined). If oversubscription causes the maximum translated addresses per rule (256) to be exceeded, the firewall will automatically reduce the oversubscription ratio in an effort to have the commit succeed. However, if your NAT rules result in translations that exceed the maximum translated addresses for the model, the commit will fail.


Dataplane NAT Memory Statistics
The show running global-ippool command displays statistics related to NAT memory consumption for a pool. The Size column displays the number of bytes of memory that the resource pool is using. The Ratio column displays the oversubscription ratio (for DIPP pools only). The lines of pool and memory statistics are explained in the following sample output:
show_running_global_ippool.png
For NAT pool statistics for a virtual system, the show running ippool command has columns indicating the memory size used per NAT rule and the oversubscription ratio used (for DIPP rules). The following is sample output for the command.
show_running_ippool.png
A field in the output of the show running nat-rule-ippool rule command shows the memory (bytes) used per NAT rule. The following is sample output for the command, with the memory usage for the rule encircled.
show_running_nat-rule-ippoool_rule.png
Configure NAT
Perform the following tasks to configure various aspects of NAT. In addition to the examples below, there are examples in the section NAT Configuration Examples .
The NAT example in this section is based on the following topology:
network_topology_diagram.png
Based on this topology, there are three NAT policies we need to create as follows:
NAT_diagram.png
·         To enable the clients on the internal network to access resources on the Internet, the internal 192.168.1.0 addresses will need to be translated to publicly routable addresses. In this case, we will configure source NAT (the purple enclosure and arrow above), using the egress interface address, 203.0.113.100, as the source address in all packets that leave the firewall from the internal zone. See Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT) for instructions.
·         To enable clients on the internal network to access the public web server in the DMZ zone, we must configure a NAT rule that redirects the packet from the external network, where the original routing table lookup will determine it should go based on the destination address of 203.0.113.11 within the packet, to the actual address of the web server on the DMZ network of 10.1.1.11. To do this you must create a NAT rule from the trust zone (where the source address in the packet is) to the untrust zone (where the original destination address is) to translate the destination address to an address in the DMZ zone. This type of destination NAT is called U-Turn NAT(the yellow enclosure and arrow above). See Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT) for instructions.
·         To enable the web server—which has both a private IP address on the DMZ network and a public-facing address for access by external users—to both send and receive requests, the firewall must translate the incoming packets from the public IP address to the private IP address and the outgoing packets from the private IP address to the public IP address. On the firewall, you can accomplish this with a single bi-directional static source NAT policy (the green enclosure and arrow above). See Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
·         Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
When a client on your internal network sends a request, the source address in the packet contains the IP address for the client on your internal network. If you use private IP address ranges internally, the packets from the client will not be able to be routed on the Internet unless you translate the source IP address in the packets leaving the network into a publicly routable address.
On the firewall you can do this by configuring a source NAT policy that translates the source address (and optionally the port) into a public address. One way to do this is to translate the source address for all packets to the egress interface on your firewall, as shown in the following procedure.
1.      Create an address object for the external IP address you plan to use.
1.      Select ObjectsAddresses and Add a Name and optional Description for the object.
2.      Select IP Netmask from the Type drop-down and then enter the IP address of the external interface on the firewall, 203.0.113.100 in this example.
3.      Click OK.
Although you do not have to use address objects in your policies, it is a best practice because it simplifies administration by allowing you to make updates in one place rather than having to update every policy where the address is referenced.
2.      Create the NAT policy.
1.      Select PoliciesNAT and click Add.
2.      On the General tab, enter a descriptive Name for the policy.
3.      (Optional) Enter a tag, which is a keyword or phrase that allows you to sort or filter policies.
4.      For NAT Type, select ipv4 (default).
5.      On the Original Packet tab, select the zone you created for your internal network in the Source Zone section (click Add and then select the zone) and the zone you created for the external network from the Destination Zone drop-down.
6.      On the Translated Packet tab, select Dynamic IP And Port from the Translation Type drop-down in the Source Address Translation section of the screen.
7.      For Address Type, there are two choices. You could select Translated Address and then click Add. Select the address object you just created.
An alternative Address Type is Interface Address, in which case the translated address will be the IP address of the interface. For this choice, you would select an Interface and optionally an IP Address if the interface has more than one IP address.
8.      Click OK.
3.      Commit your changes.
Click Commit.
4.      (Optional) Access the CLI to verify the translation.
1.      Use the show session all command to view the session table, where you can verify the source IP address and port and the corresponding translated IP address and port.
2.      Use the show session id <id_number> to view more details about a session.
3.      If you configured Dynamic IP NAT, use the show counter global filter aspect session severity drop | match nat command to see if any sessions failed due to NAT IP allocation. If all of the addresses in the Dynamic IP NAT pool are allocated when a new connection is supposed to be translated, the packet will be dropped.
·         Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
When a user on the internal network sends a request for access to the corporate web server in the DMZ, the DNS server will resolve it to the public IP address. When processing the request, the firewall will use the original destination in the packet (the public IP address) and route the packet to the egress interface for the untrust zone. In order for the firewall to know that it must translate the public IP address of the web server to an address on the DMZ network when it receives requests from users on the trust zone, you must create a destination NAT rule that will enable the firewall to send the request to the egress interface for the DMZ zone as follows.
1.      Create an address object for the web server.
1.      Select ObjectsAddresses and Add a Name and optional Descriptionfor the object.
2.      Select IP Netmask from the Type drop-down and enter the public IP address of the web server, 203.0.113.11 in this example.
3.      Click OK.
2.      Create the NAT policy.
1.      Select PoliciesNAT and click Add.
2.      On the General tab, enter a descriptive Name for the NAT rule.
3.      On the Original Packet tab, select the zone you created for your internal network in the Source Zone section (click Add and then select the zone) and the zone you created for the external network from the Destination Zone drop-down.
4.      In the Destination Address section, Add the address object you created for your public web server.
5.      On the Translated Packet tab, select Destination Address Translationand then enter the IP address that is assigned to the web server interface on the DMZ network, 10.1.1.11 in this example.
6.      Click OK.
3.      Commit.
Click Commit.
4.Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
When your public-facing servers have private IP addresses assigned on the network segment where they are physically located, you need a source NAT rule to translate the source address of the server to the external address upon egress. You create a static NAT rule to translate the internal source address, 10.1.1.11, to the external web server address, 203.0.113.11 in our example.
However, a public-facing server must be able to both send and receive packets. You need a reciprocal policy that translates the public address (the destination IP address in incoming packets from Internet users) into the private address so that the firewall can route the packet to your DMZ network. You create a bi-directional static NAT rule, as described in the following procedure. Bi-directional translation is an option for static NAT only.
1.      Create an address object for the web server’s internal IP address.
1.      Select ObjectsAddresses and Add a Name and optional Description for the object.
2.      Select IP Netmask from the Type drop-down and enter the IP address of the web server on the DMZ network, 10.1.1.11 in this example.
3.      Click OK.
If you did not already create an address object for the public address of your web server, you should create that object now.
2.      Create the NAT policy.
1.      Select PoliciesNAT and click Add.
2.      On the General tab, enter a descriptive Name for the NAT rule.
3.      On the Original Packet tab, select the zone you created for your DMZ in the Source Zonesection (click Add and then select the zone) and the zone you created for the external network from the Destination Zone drop-down.
4.      In the Source Address section, Add the address object you created for your internal web server address.
5.      On the Translated Packet tab, select Static IP from the Translation Type drop-down in the Source Address Translation section and then select the address object you created for your external web server address from the Translated Address drop-down.
6.      In the Bi-directional field, select Yes.
7.      Click OK.
3.      Commit.
Click Commit.
4.      Next
Modify the Oversubscription Rate for DIPP NAT
If you have enough public IP addresses that you do not need to use DIPP NAT oversubscription, you can reduce the oversubscription rate and thereby gain more DIP and DIPP NAT rules allowed.
1.      View the DIPP NAT oversubscription rate.
1.      Select DeviceSetupSessionSession Settings. View the NAT Oversubscription Rate setting.
2.      Set the DIPP NAT oversubscription rate.
1.      Edit the Session Settings section.
2.      In the NAT Oversubscription Rate drop-down, select 1x2x4x, or 8x, depending on which ratio you want.
The Platform Default setting applies the default oversubscription setting for the model. If you want no oversubscription, select 1x.
3.      Click OK and Commit the change
4.Disable NAT for a Specific Host or Interface
Both source NAT and destination NAT rules can be configured to disable address translation. You may have exceptions where you do not want NAT to occur for a certain host in a subnet or for traffic exiting a specific interface. The following procedure shows how to disable source NAT for a host.
1.      Create the NAT policy.
1.      Select PoliciesNAT and click Add a descriptive Name for the policy.
2.      On the Original Packet tab, select the zone you created for your internal network in the Source Zone section (click Add and then select the zone) and the zone you created for the external network from the Destination Zone drop-down.
3.      For Source Address, click Add and enter the host address. Click OK.
4.      On the Translated Packet tab, select None from the Translation Type drop-down in the Source Address Translation section of the screen.
5.      Click OK.
2.      Commit your changes.
Click Commit.
NAT rules are processed in order from the top to the bottom, so place the NAT exemption policy before other NAT policies to ensure it is processed before an address translation occurs for the sources you want to exempt.
3.Reserve Dynamic IP NAT Addresses
You can reserve Dynamic IP NAT addresses (for a configurable period of time) to prevent them from being allocated as translated addresses to a different source IP address that needs translation. When configured, the reservation applies to all of the translated Dynamic IP addresses in progress and any new translations.
For both translations in progress and new translations, when a source IP address is translated to an available translated IP address, that pairing is retained even after all sessions related to that specific source IP are expired. The reservation timer for each source IP address begins after all sessions that use that source IP address translation expire. Dynamic IP NAT is a one-to-one translation; one source IP address translates to one translated IP address that is chosen dynamically from those addresses available in the configured pool. Therefore, a translated IP address that is reserved is not available for any other source IP address until the reservation expires because a new session has not started. The timer is reset each time a new session for a source IP/translated IP mapping begins, after a period when no sessions were active.
By default, no addresses are reserved. You can reserve Dynamic IP NAT addresses for the firewall or for a virtual system.
§  Reserve dynamic IP NAT addresses for a firewall.
Enter the following commands:
admin@PA-3020# set setting nat reserve-ip yes
admin@PA-3020# set setting nat reserve-time <1-604800 secs>
§  Reserve dynamic IP NAT addresses for a virtual system.
Enter the following commands:
admin@PA-3020# set vsys <vsysid> setting nat reserve-ip yes
admin@PA-3020# set vsys <vsysid> setting nat reserve-time <1-604800 secs>
For example, suppose there is a Dynamic IP NAT pool of 30 addresses and there are 20 translations in progress when the nat reserve-time is set to 28800 seconds (8 hours). Those 20 translations are now reserved, so that when the last session (of any application) that uses each source IP/translated IP mapping expires, the translated IP address is reserved for only that source IP address for 8 hours, in case that source IP address needs translation again. Additionally, as the 10 remaining translated addresses are allocated, they each are reserved for their source IP address, each with a timer that begins when the last session for that source IP address expires.
In this manner, each source IP address can be repeatedly translated to its same NAT address from the pool; another host will not be assigned a reserved translated IP address from the pool, even if there are no active sessions for that translated address.
Suppose a source IP/translated IP mapping has all of its sessions expire, and the reservation timer of 8 hours begins. After a new session for that translation begins, the timer stops, and the sessions continue until they all end, at which point the reservation timer starts again, reserving the translated address.
The reservation timer remain in effect on the Dynamic IP NAT pool until you disable it by entering the set setting nat reserve-ip no command or you change the nat reserve-time to a different value.
The CLI commands for reservations do not affect Dynamic IP and Port (DIPP) or Static IP NAT pools.
                                                                                                  
NAT Configuration Examples
4.                 

No comments:

Post a Comment