Friday 16 June 2017

Palo Alto - NAT Configuration Examples

Destination NAT Example—One-to-One Mapping
The most common mistakes when configuring NAT and security rules are the references to the zones and address objects. The addresses used in destination NAT rules always refer to the original IP address in the packet (that is, the pre-translated address). The destination zone in the NAT rule is determined after the route lookup of the destination IP address in the original packet (that is, the pre-NAT destination IP address).
The addresses in the security policy also refer to the IP address in the original packet (that is, the pre-NAT address). However, the destination zone is the zone where the end host is physically connected. In other words, the destination zone in the security rule is determined after the route lookup of the post-NAT destination IP address.
In the following example of a one-to-one destination NAT mapping, users from the zone named untrust-l3 access the server 10.1.1.100 in the zone named dmz-l3 using the IP address 1.1.1.100.
Before configuring the NAT rules, consider the sequence of events for this scenario.
Host 1.1.1.250 sends an ARP request for the address 1.1.1.100 (the public address of the destination server).The firewall receives the ARP request packet for destination 1.1.1.100 on the Ethernet1/1 interface and processes the request. The firewall responds to the ARP request with its own MAC address because of the destination NAT rule configured.The NAT rules are evaluated for a match. For the destination IP address to be translated, a destination NAT rule from zone untrust-l3 to zone untrust-l3 must be created to translate the destination IP of 1.1.1.100 to 10.1.1.100.After determining the translated address, the firewall performs a route lookup for destination 10.1.1.100 to determine the egress interface. In this example, the egress interface is Ethernet1/2 in zone dmz-l3.The firewall performs a security policy lookup to see if the traffic is permitted from zone untrust-l3 to dmz-l3.
The direction of the policy matches the ingress zone and the zone where the server is physically located.
The security policy refers to the IP address in the original packet, which has a destination address of 1.1.1.100.
The firewall forwards the packet to the server out egress interface Ethernet1/2. The destination address is changed to 10.1.1.100 as the packet leaves the firewall.
For this example, the following address objects are configured:
The configured NAT rule would look like this:
The direction of the NAT rules is based on the result of route lookup.
The configured security policy to provide access to the server from the untrust-l3 zone would look like this:
Destination NAT with Port Translation Example
In this example, the web server is configured to listen for HTTP traffic on port 8080. The clients access the web server using the IP address 1.1.1.100 and TCP Port 80. The destination NAT rule is configured to translate both IP address and port to 10.1.1.100 and TCP port 8080.
The following NAT and security rules must be configured on the firewall:
Use the show session all CLI command to verify the translation.
Destination NAT Example—One-to-Many Mapping
In this example, one IP address maps to two different internal hosts. The firewall uses the application to identify the internal host to which the firewall forwards the traffic.
All HTTP traffic is sent to host 10.1.1.100 and SSH traffic is sent to server 10.1.1.101. The following address objects are required:
Address object for the one pre-translated IP address of the serverAddress object for the real IP address of the SSH serverAddress object for the real IP address of the web server
The configured address objects would look like this:
The NAT rules would look like this:
The security rules would look like this:
Source and Destination NAT Example
In this example, NAT rules translate both the source and destination IP address of packets between the clients and the server.
Source NAT—The source addresses in the packets from the clients in the l3-trust zone to the server in the l3-untrust zone are translated from the private addresses in the network 192.168.1.0/24 to the IP address of the egress interface on the firewall (10.16.1.103). Dynamic IP and Port translation causes the port numbers to be translated also.Destination NAT—The destination addresses in the packets from the clients to the server are translated from the server’s public address (80.80.80.80) to the server’s private address (10.2.133.15).
The following address objects are created for destination NAT.
Server-Pre-NAT: 80.80.80.80Server-post-NAT: 10.2.133.15
The following screen shots illustrate how to configure the source and destination NAT policies for the example.
To verify the translations, use the CLI command show session all filter destination 80.80.80.80 . Note that a client address 192.168.1.11 and its port number are translated to 10.16.1.103 and a port number. The destination address 80.80.80.80 is translated to 10.2.133.15.
Virtual Wire Source NAT Example
Virtual wire deployment of a Palo Alto Networks firewall includes the benefit of providing security transparently to the end devices. It is possible to configure NAT for interfaces configured in a virtual wire. All of the NAT types are allowed: source NAT (Dynamic IP, Dynamic IP and Port, static) and destination NAT.
Because interfaces in a virtual wire do not have an IP address assigned, it is not possible to translate an IP address to an interface IP address. You must configure an IP address pool.
The firewall will not proxy ARP for NAT addresses. Ensure that routes are configured on the upstream and downstream devices. See Proxy ARP for NAT Address Pools for more explanation about proxy ARP.
Proper routing must be configured on the upstream and downstream routers in order for the packets to be translated in virtual wire mode.
In the source NAT and static NAT examples below, security policies (not shown) are configured from the virtual wire zone named vw-trust to the zone named vw-untrust.
In the following topology, two routers are configured to provide connectivity between subnets 1.1.1.0/24 and 3.1.1.0/24. The link between the routers is configured in subnet 2.1.1.0/30. Static routing is configured on both routers to establish connectivity between the networks. Before the firewall is deployed in the environment, the topology and the routing table for each router look like this:
Route on R1:
DestinationNext Hop
3.1.1.0/242.1.1.2
Route on R2:
DestinationNext Hop
1.1.1.0/242.1.1.1
Now the firewall is deployed in virtual wire mode between the two Layer 3 devices. All communications from clients in network 1.1.1.0/24 accessing servers in network 3.1.1.0/24 are translated to an IP address in the range 2.1.1.9-2.1.1.14. A NAT IP address pool with range 2.1.1.9-2.1.1.14 is configured on the firewall.
All connections from the clients in subnet 1.1.1.0/24 will arrive at router R2 with a translated source address in the range 2.1.1.9-2.1.1.14. The response from servers will be directed to these addresses. In order for source NAT to work, you must configure proper routing on router R2, so that packets destined for other addresses are not dropped. The routing table below shows the modified routing table on router R2. The route ensures the traffic to the destinations 2.1.1.9-2.1.1.14 (that is, hosts on subnet 2.1.1.8/29) will be sent back through the firewall to router R1.
Route on R2:
DestinationNext Hop
2.1.1.8/292.1.1.1
Virtual Wire Static NAT Example
In this example, security policies are configured from the virtual wire zone named vw-trust to vw-untrust. Host 1.1.1.100 is statically translated to address 2.1.1.100. With the Bi-directional option enabled, the firewall generates a NAT policy from the vw-untrust zone to the vw-trust zone. Clients on the vw-untrust zone access the server using the IP address 2.1.1.100, which the firewall translates to 1.1.1.100. Any connections initiated by the server at 1.1.1.100 are translated to source IP address 2.1.1.100.
Route on R2:
DestinationNext Hop
2.1.1.100/322.1.1.1
Virtual Wire Destination NAT Example
Clients in the vw-untrust zone access the server using the IP address 2.1.1.100, which the firewall translates to 1.1.1.100. Both the NAT and security policies must be configured from the vw-untrust zone to the vw-trust zone.
Route on R2:
DestinationNext Hop
2.1.1.100/322.1.1.1

No comments:

PAN-OS Supported ciphers

Following is a list of supported ciphers for PAN-OS 7.1 and later: SSLv3 Ciphers Supported (No change from PAN-OS 7.0) Non-FIPS mod...