Management Articles

Featured Article
https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Check-the-NAT-Buffer-Pool/ta-p/57039
View full article
Farman ‎08-02-2018 01:27 PM
1,468 Views
0 Replies
DNS rewrite (DNS doctoring) is a  capability that some NAT devices offer in order to translate the DNS A-record for a particular DNS query. The Palo Alto Networks firewall as of now does not support the DNS doctoring feature, but there are a few workarounds that can be used.    Some scenarios in which DNS doctoring applies.   Scenario 1:  External DNS Server is returning the public IP of an application server to a client who is also sitting behind the same firewall.        Traffic Flow in this case: In the above case, DNS server 4.2.2.2 replies to the DNS query of the client with the public IP of the Web server, for example 198.51.100.3. The client now accesses the web server on the public IP and forwards that request to the Firewall.  The firewall tries to do route lookup for  198.51.100.3 IP and finds a route via Eth1/1 (Untrust Zone) pointing to the ISP and sends the packet out.   A firewall capable of DNS rewriting will translate the IP address in the DNS response to the private IP address of the server since it has NAT mapping for the same, which enables the client to directly access the Server through LAN to LAN routing/ policies.   Workarounds Configure the client to use the firewall as DNS proxy, and on Firewall configure a static entry for www.example.com as 10.1.1.3. For all other lookups the firewall can use 4.2.2.2 as the DNS server. How to Configure DNS Proxy on a Palo Alto Networks Firewall   OR Use U-Turn NAT, thereby forwarding the traffic from the client to the Server: How to Configure U-Turn NAT   Scenario 2: Internal DNS server is returning private IP address of application server to both Internal and external users.   The external user will not be able to access the server, since it will get the private IP address of the Web Server.    Workaround Add a secondary DNS server (preferably in a DMZ zone) to serve external clients with a public IP address to the server. Change the DNS Server’s A record to use the public IP of the Web Server, and then use the U Turn NAT solution as in Case 1 for the internal Client to be able to access the Web Server. Some DNS servers, like bind9, can serve different records depending on the source IP of the requestor    
View full article
abjain ‎10-30-2017 07:22 AM
8,732 Views
0 Replies
1 Like
Details   To display the NAT IP pool cache, run the show running ippool command:   > show running ippool   VSYS 1 has 3 NAT rules, DIP and DIPP rules: Rule                             Type            Used       Available  Mem Size Ratio -------------------------------- --------------- ---------- ---------- -------- ----- Trusted-to-Untrusted             Dynamic IP/Port 273        128751        20336    2   In the above example from PAN-OS 7.1, the NAT rule, Trusted-to-Untrusted, is using 273 buffers out of 128751 at present for NAT operation. The RATIO is also known as the over-subscription rate. The RATIO varies among platforms, this one being a PA-200. It specifies the number of sessions from one source IP and port combination to different destination IPs that can use the same source port in the translation.   There are a total of 65536 high TCP ports. The first 1024 are reserved, leaving the firewall with  64512 to choose from in a DIPP (dynamic ip-and-port) NAT rule. Multiply 64512 by the ratio and the product is the total number of ports available, which is 129024, the sum of 273 and 128751 in the output above.   To reclaim the NAT buffers, which only clears the stale buffers and not the current NAT which is in use in an existing session, run the following command: > debug dataplane nat sync-ippool rule <rulename>   To clear the value and all sessions, run the following command: > clear session all   To check a specific NAT rule IP pool usage, use the show running nat-rule-ippool show-freelist yes rule <NAT-rule-name> command:   > show running nat-rule-ippool show-freelist yes rule Trusted-to-Untrusted VSYS 1 Rule yes: Rule: Trusted-to-Untrusted, Pool index: 1, memory usage: 20336 ----------------------------------------- Oversubscription Ratio:                2 Number of Allocates:               34285 Last Allocated Index:               1339   Oversubscription Ratio: Indicates  the number of sessions from one source IP and port combination to  different  destination IPs that can use the same source port in the translation.    
View full article
apasupulati ‎07-05-2017 11:12 AM
25,540 Views
8 Replies
Issue In ideal setup we create IPSEC tunnel and use PBF rule to forward the traffic to tunnel if IPSEC vpn failover is required. Note: To configure Dual ISP and automatic VPN failover follow the below document: How to Setup a Palo Alto Networks Firewall with Dual ISPs and Automatic VPN Failover   We also configure the monitoring IP (IP which is across the tunnel) to perform the tunnel monitoring.   If we have overlapping subnet, we will configure source NAT in order to avoid routing issue on the other end of tunnel. With this setup PBF rule might not work and you could see the PBF rule gets disabled   Cause When enabling PBF monitoring, firewall will send keep alive messages with egress interface as source and send the packets out. If we manually ping the monitoring IP sourcing from egress interface IP, this traffic will go through route lookup and NAT lookup. Subsequently this traffic will get source NAT-ed and we will get ping replies. However the keep alive messages will not go through route lookup and for the same reason it will not be NAT-ed. This might cause routing issue on the other end and we might not get keep alive replies which in turn cause our PBF rule to disable.   Rule: PBF VPN1(6) Rule State: Disabled Action: Forward Symmetric Return: No Egress IF/VSYS: tunnel.1 NextHop: 0.0.0.0 Monitor Slot: 1 Monitor IP: 170.66.50.11 NextHop Status: DOWN Monitor: Action:Fail-Over, Interval:3, Threshold:5 Stats: KA sent:2971, KA got:0 , Packet Matched:28675   Workaround Configure a public IP on the tunnel interface and on the other end of tunnel create a static route for this public IP pointing to the tunnel.   owner: skumar1
View full article
skumar1 ‎09-11-2015 01:15 AM
7,509 Views
0 Replies
3 Likes
Symptom Cannot ping default gateway. The firewall seems to not build dynamically an ARP entry for the IP of its default gateway.   Resolution Review your NAT policies.   The firewall performs proxy ARP on the IPs configured for inbound NAT as destinations. A network object that includes the IP address of the default gateway is commonly used in the destination field of a NAT rule. This will result in the proxy ARP process preventing the firewall from building an ARP entry for the firewall's default gateway.   owner: parmas  
View full article
parmas ‎09-10-2015 09:38 AM
4,948 Views
0 Replies
Issue While attempting to commit changes, the following error message is displayed:   Error: Number of dynamic-ip-and-port rules (451) exceeds vsys capacity (450) Error: Failed to parse nat policy (Module: device) Commit failed   Note: This error will occur when too many rules are in place, but the first number (451 in this example) will always be 1 above the limit regardless of how many actual rules are in the policy. This is because the error triggers as soon as the firewall exceeds the it's limit.   Resolution There is a maximum number of NAT rules that can be configured per virtual system (VSYS) and this error will occur if the number of NAT rules in the policy exceeds that number.   The solution is to consolidate NAT rules to lower the number of active rules in the policy to be installed.   See Also For information on finding out the limit on NAT rules please see the following article: How to view the Maximum limit of NAT rules   owner: swhyte
View full article
npare ‎09-09-2015 02:01 PM
2,142 Views
0 Replies
Issue Unable to reach the server's public IP address. Details a second public range is configured on interface e1/2 while physical host is located on e1/3 NAT rules are configured from untrust to untrust. Cause The server's public IP address is in the same address space as the IP address of another interface on the Palo Alto Networks firewall. Example: e1/1, zone untrust, public IP 1.1.1.1/24 e1/2, zone DMZ-Public, IP 2.2.2.2/24 e1/3, zone DMZ-Private, IP 192.168.1.1/24 (server is connected to e1/3, public IP 2.2.2.66/24, private IP 192.168.1.2/24) NAT policy set for "untrust zone to untrust zone". The firewall sees the ingress traffic's destination IP address (2.2.2.66) as destined for the "DMZ-Public" zone. This is because a route lookup returns DMZ-Public as the destination zone for 2.2.2.0/24.   However, the policy specifies that traffic from "untrust to untrust" is allowed.  Therefore, the traffic is dropped. Resolution Edit the NAT policy. Change the destination zone to "DMZ-Public". Changing the destination zone from "untrust" to "DMZ-Public" causes the ingress traffic to properly match source and destination zone, based on route lookups   owner: jdavis
View full article
panagent ‎09-07-2015 06:01 AM
3,141 Views
0 Replies
Issue Traffic is not passing destination NAT rule. A flow debug shows the following error: vsys 1 NAT rule index 5 result in LAND attack, same SA/DA <IP> Resolution The NAT rule was translating the source address and not the destination address. This causes the protection to kick in. The traffic will not work due to the wrong translation and the packets are dropped because they represent a LAND attack.   owner: jseals
View full article
panagent ‎09-03-2015 01:11 PM
2,264 Views
0 Replies
Details When translating proxy IDs over IPsec tunnels using NAT, pointing the routes of the NAT-translated IPs through the tunnel interfaces is required.   The diagram is a typical setup where customers hide private IP addresses on their sites by using public addresses and NAT. (For a larger image, see the attachment below.)   On the PA 2020: 172.17.20.0/24 is NATed out to the 2.2.2.0/24 network.   On the PA 5050: 172.17.30.0/24 is NATed out to the 3.3.3.0/24 network.   NAT need not always be a one-to-one mapping. Customers can also deploy port-based translation to single public IP addresses. These IP addresses are used as proxy IDs for the VPN. Per the PAN-OS session setup, the firewall decrypts the ESP packet, then performs the forwarding lookup for both the source IP and the destination IP, of the inside packet, to determine the interface and the zone for both IP addresses. If the route to these IP addresses is not pointed to the tunnel interface, the forwarding lookup points the addresses to the default gateway (assuming there is neither a  static route configured for these IP addresses or that they're being learned dynamically). As both IP addresses have routes pointing to the untrust interface and the untrust zone, it doesn't  match the policy permitting traffic from the zone that the tunnel interface belongs to, so the packets get dropped.   The route configurations required in addition to NAT and VPN settings are:   admin@PA-2020# set network virtual-router default routing-table ip static-route local-site-NAT destination 2.2.2.0/24  interface tunnel.1 admin@PA-2020# set network virtual-router default routing-table ip static-route local-site-NAT destination 3.3.3.0/24  interface tunnel.1   Similarly, the route configuration on the other firewall would look like:   admin@PA-5050# set network virtual-router default routing-table ip static-route local-site-NAT destination 3.3.3.0/24  interface tunnel.1 admin@PA-5050# set network virtual-router default routing-table ip static-route local-site-NAT destination 2.2.2.0/24  interface tunnel.1
View full article
kprakash ‎09-02-2015 05:02 PM
25,422 Views
4 Replies
1 Like
Issue Receiving the following error message on commit: device: nat rule 'NAT_rule': Mismatch static-ip address range between original address and translated addressFailed to parse nat policyCommit failed   Cause Using a subnet /24 to translate to one static IP.  This is not allowed or supported.   Resolution Need to use a /32 address to translate to one static IP.   owner: panagent
View full article
panagent ‎08-27-2015 06:34 PM
10,264 Views
0 Replies
3 Likes
Issue Source NAT is configured and it's not possible to ping an external interface from an internal host.   Cause Pinging from an internal host to an external interface when using source NAT is an incorrect test method.  Packets are dropped since the source address is the external address of the firewall and the destination address is the same.  Packets are dropped by a security measure called a LAND attack.   In the CLI, global counters can reveal any LAND attacks caused by misconfigured NAT rules : > show counter global filter packet-filter yes | match nat_land flow_policy_nat_land   drop      Session setup: source NAT IP allocation result in LAND attack   Resolution Create Address Object for External IP. 2. Create a rule with No Translation for traffic destined for that IP Address.   owner:  nayubi
View full article
panagent ‎08-27-2015 05:01 PM
7,008 Views
0 Replies
Issue Commit operations fail with the following error: Error updating NAT IP pools failed to handle CONFIG_UPDATE_START.   Cause The commit error is due to the current NAT configuration exceeding memory limitations on the device.   The NAT pool total memory is allocated at 50% for current running config, 50% for a candidate config being committed. The memory is split 50/50 because we cannot clear the memory and allocate for the new candidate configuration, as that operation would disrupt existing sessions which are using NAT. Any configuration being committed to the device must stay below the 50% limit of the NAT memory pool. If the 50% limit is exceeded, a new candidate configuration which has modified NAT policies will experience a commit failure similar to the one encountered.   In PAN-OS 4.1.x, the process which validates that the configuration does not exceed the 50% limit is not implemented. As a result, NAT can be configured in a way that exceeds the limit, causing subsequent NAT changes to fail during the commit when memory is attempted to be allocated.   In PAN-OS 5.0.x, a check is made prior to any commit to validate that the configured NAT policies will not exceed the 50% threshold. This added validation would cause the configuration on a PAN-OS 5.0 device to fail to commit even after a dataplane restart.   Resolution 1. Remove some NAT policies. 2. Reduce the IP address pool size in the NAT policies.   From : (in reference to Issue 48497) Environments with a large number of NAT DIP/DIPP rules may experience an error condition committing or upgrading to PAN-OS 5.0: Error updating NAT IP pools failed to handle CONFIG_UPDATE_START . To help you reconfigure NAT rules to use less memory, information about memory usage has been added to the show running nat-policy CLI command showing NAT rule memory usage by VSYS. You can either delete unnecessary NAT rules or compress NAT rules to reduce memory utilization. For example, you could compress DIPP NAT translation from a /27 address range to a /32 IP address.   owner: pvemuri
View full article
pvemuri ‎08-26-2015 06:18 AM
4,582 Views
0 Replies
1 Like
Overview LAND attacks can occur when an administrator configures destination translation for a DMZ zone server and source translation for Trust zone users with same public IP address. When traffic from internal LAN to the firewall public IP address source translation will be applied and dropped by the Palo Alto Networks firewall, which is considered to be a LAND attack. Details Shown below is the scenario where traffic can be dropped due to a LAND attack. Traffic initiated from the "Trust_L3" zone to the internet will use source translation. The traffic initiated from the public network (Untrust_L3) to the web server (200.1.1.1) will use destination translation. Here is the NAT configuration for the above scenario. Traffic from an internal zone (Trust_L3) to the firewall public IP address (200.1.1.1) will hit the source NAT rule, which will cause a source translation to be applied to the traffic. The source will be translated to the public IP of the firewall and the firewall will immediately drop this traffic because it will be considered a LAND attack. The firewall would see this traffic as the same source and destination IP address. Resolution To confirm that traffic is being dropped due to a LAND attack, run the following command. This command verifies counters, specifically the drop counters. A filter can be configured with a specific source and destination IP address and applied to global counters to get the specific outputs, as shown below. After setting the filters and initiating the "Ping" traffic to the firewall public IP from internal LAN, follow the below command to check for the drops due to LAND attack. > show counter global filter packet-filter yes delta yes severity drop Global counters: Elapsed time since last sampling: 17.60  seconds name                     value     rate severity  category  aspect    description --------------------------------------------------------------------------------- flow_policy_nat_land      3         0   drop      flow      session   Session setup: source NAT IP allocation result in LAND attack --------------------------------------------------------------------------------- Total counters shown: 1 --------------------------------------------------------------------------------- Resolution Create a "No NAT" rule for traffic from internal LAN (Trust_L3) to the firewall IP address (200.1.1.1), as shown below. Traffic from the internal LAN Trust_L3 to the firewall IP address (200.1.1.1) will hit the "No NAT" rule and not be subject to NAT translation. owner: sbabu
View full article
sbabu ‎09-27-2014 02:50 PM
7,432 Views
0 Replies
1 Like
Overview The maximum number of translations that the Palo Alto Networks firewall can perform when a Port Address Translation is configured, until it uses up the available ports on a rule, is around 64,000-1,000. The lower 1024 ports are never used because they are considered servers' ports. To accommodate for a bigger number of translations on a given NAT rule, on Palo Alto Networks devices PA-3000, PA-4000, PA-5000, and PA-7000 there is an option for oversubscription. This is a preconfigured setting and no change is needed on the device to enable it. Steps To check for oversubscription on a security rule, use the following command: > show running nat-rule-ippool rule nat1 VSYS 1 Rule nat1: Rule: nat1, Pool index: 1, memory usage: 20336 ----------------------------------------- Oversubscription Ratio:                2 Number of Allocates:                9327 Last Allocated Index:              54528 The above output indicates that a security rule is oversubscribed twice, which is the value on the 3050 device. The other devices have a different ratio of oversubscription. For example, the 5050/5060 have a factor of 8. owner: ialeksov
View full article
ialeksov ‎09-13-2014 05:05 AM
6,089 Views
0 Replies
Issue There can be two symptoms: The Palo Alto Networks firewall has an incomplete ARP entry for a host on the network (for example, default gateway): > show arp all maximum of entries supported :      2500 default timeout:                    1800 seconds total ARP entries in table :        1 total ARP entries shown :           1 status: s - static, c - complete, e - expiring, i - incomplete interface         ip address      hw address        port              status   ttl -------------------------------------------------------------------------------- ethernet1/4       10.108.121.1    (incomplete)      ethernet1/4         i      1 The firewall is responding to every ARP request on the network. On the endpoint, select any random IP address, try to ping it and you'll see an ARP entry with the firewall's IP MAC: $ ping -w 2  10.108.121.251 $ ping -w 2  10.108.121.252 $ arp -an ? (10.108.121.251) at 00:1b:17:00:04:13 [ether] on eth4 ? (10.108.121.252) at 00:1b:17:00:04:13 [ether] on eth4 Cause It is likely there is an incorrectly configured source NAT policy with a mask length that is not /32. For example, if an interface is configured with IP address 10.108.121.2/24, then the NAT IP should be configured as 10.108.121.3/32 (with /32 mask). The NAT IP in this example should not be configured as 10.108.121.3/24. Resolution With a large number of NAT rules, it can be difficult to narrow down the policy. Three methods to identify the NAT rule are described below. The first two are safe to perform, the third option involves enabling debugs on the dataplane and should be used cautiously. Method 1 Identify the offending pool: > show running global-ippool Idx  Type             From                             To              Num   Ref. Cnt ---- ---------------- -------------------------------- --------------- ---   ---------- 3    Dynamic IP/Port  0.0.0.0-255.255.255.255          10.108.121.5    1     1 6    Dynamic IP/Port  0.0.0.0-255.255.255.255          10.108.121.0    256   1 Note: Pool 6 is using 256 addresses in 10.108.121.0 network. To determine which policy, run the following command, then press "/" (slash), then type in: "idx: 6" (there is space between double colon and 6 and if needed go back a little bit by pressing the up arrow key). > show running nat-policy [...] dmz_Out {         from dmz;         source any;         to outside;         to-interface ethernet1/4 ;         destination any;         service  any/any/any;         translate-to "src: 10.108.121.0-10.108.121.255 (dynamic-ip-and-port) (pool idx: 6)";         terminal no; } See the incorrectly configured rule is dmz_out. Method 2 Run a single command, which basically tells the firewall to output all rule names and src NAT translations, where a range of IPs is used. In this case, the rule name that precedes the translation is the offending rule. > show running nat-policy | match {\|src:[^\(]*- "Rule 1" { smtp04-in { smtp04-out { smtp03-out { "Internet outbound" { dmz_Out {         translate-to "src: 10.108.121.0-10.108.121.255 (dynamic-ip-and-port) (pool idx: 6)"; "Rule 4" { "Rule 5" { smtp03-in { Method 3 Important! Use cautiously, because this method enables debugs on the dataplane. Enable debug on DP: > debug dataplane packet-diag clear all > debug dataplane packet-diag set filter match non-ip only > debug dataplane packet-diag set filter on > debug dataplane packet-diag set log feature flow arp > debug dataplane packet-diag set log on > debug dataplane packet-diag clear log log After trying to send the communication through the firewall (or pinging from the firewall default gateway): > ping source 10.108.121.253 host 10.108.121.1 Review the DP debug files: > less dp-log pan_task_* It is possible to go to the next file by pressing "n" At some point, the following appears, which may be similar to: Received ARP packet from port ethernet1/4 Packet decoded dump: L2:     00:50:56:a3:10:5a->00:1b:17:00:04:13, type 0x0806 ARP:    hardware type 0x0001         protocol type 0x0800         hardware size 6         protocol size 4         opcode REPLY         sender mac address 00:50:56:a3:10:5a         sender ip address 10.108.121.1         target mac address 00:1b:17:00:04:13         target ip address 10.108.121.253 ARP packet sent from translated IP in NAT rule index 5 in vsys 1 ARP packet sent to interface ethernet1/4 IP ARP packet parse complete, learn: no, target myself: yes, gratuitous ARP: no In the example above, the firewall states that someone is using the IP address, which firewall it is using in NAT rule index 5. Note: Index 5 means only active policies (disabled policies do not count) and it starts from 0. The easiest way is to again run command " > show running nat-policy " and count policies. Fix Details This is how the rule looked in the WebGUI and CLI:                > show config running [...] dmz_Out {      to outside;      from dmz;      source any;      destination any;      service any;      nat-type ipv4;      source-translation {           dynamic-ip-and-port {                translated-address 10.108.121.211;           }      }      to-interface ethernet1/4; } At a glance, there is nothing wrong with this rule, however after some investigation see that the 10.108.121.211 is really an object:           10.108.121.211 {               ip-netmask 10.108.121.211/24;             } This would be difficult to find just by browsing through the WebUI. Change the netmask to the appropriate one (most likely /32) and verify. See how the rule looks after the change: > show running nat-policy dmz_Out {         from dmz;         source any;         to outside;         to-interface ethernet1/4 ;         destination any;         service  any/any/any;         translate-to "src: 10.108.121.211 (dynamic-ip-and-port) (pool idx: 7)";         terminal no; } > show running global-ippool Idx  Type             From                             To              Num   Ref. Cnt ---- ---------------- -------------------------------- --------------- ---   ---------- 3    Dynamic IP/Port  0.0.0.0-255.255.255.255          10.108.121.5    1     1 7    Dynamic IP/Port  0.0.0.0-255.255.255.255          10.108.121.211  1     1 In the example above, note a different pool ID used by the very same rule, but only a single IP address is used. This behavior is seen in PAN-OS 6.0 only, but seems to work fine in earlier releases. owner: rweglarz
View full article
RafalWeglarz ‎07-30-2014 07:01 AM
52,423 Views
4 Replies
5 Likes
Issue The Palo Alto Networks firewall has an interface configured for an ISP address (ISP1) in the Untrust Zone. This ISP address is not reachable from any public IP ( X.X.X.X) coming from the untrust zone. However, when a ping is sourced from the ISP1 address to the X.X.X.X, it works fine. Cause There is a NAT rule on the Palo Alto Networks firewall from source zone Untrust to destination zone Untrust, which NATs all the source traffic to the ISP1 address. When the traffic comes in from X.X.X.X to ISP1, the X.X.X.X is NATed to ISP1 address since it is Untrust to Untrust traffic. The firewall sees the traffic coming in from ISP1 and destined to ISP1, and hence drops the traffic as a LAND attack. When the traffic is sourced from the ISP1 to X.X.X.X, the traffic is Source NATed as ISP1 address and reaches the internet as ISP1. Thus, the same behavior is not observed. Resolution Remove the NAT rule which translates traffic coming from any public IP in the Untrust zone which is destined for the Untrust zone as the ISP address on the Palo Alto Networks firewall (ISP1, in this case). owner: achalla
View full article
achalla ‎07-21-2014 11:44 PM
5,204 Views
0 Replies
Issue Implementing destination address translation results in the following commit error: Mismatch of destination address translation range between original address and translated address On the NAT policy, the configured items appear valid as shown in the example below: Cause The destination address (shown above)'10.10.10.20', is NOT actually an address, but an address object with name as IP address as shown below: Resolution Change the name to help clarify, and change this address to be a single IP or with a /32 to resolve this issue. owner: hyadavalli
View full article
hyadavalli ‎04-17-2014 07:14 PM
12,038 Views
1 Reply
2 Likes
Issue Occasionally, on a site-to-site IPSec VPN between a Palo Alto Networks device and another device, Phase 1 and Phase 2 will be up. However, the hosts behind the peer are not reachable. Details Determine what zone the tunnel interface is located. If the tunnel interface is in the untrust zone, the traffic will be NATed to the public IP, while leaving the tunnel, by the default NAT rule on the Palo Alto Networks device. Resolution There are two options to resolve this issue: Move the tunnel interface to one of the inside zones, so that the traffic will not get NATed while leaving the tunnel. Create a No-NAT rule for traffic from the inside zones to those destination addresses behind the peer. owner: achalla
View full article
achalla ‎04-09-2014 03:39 AM
10,829 Views
2 Replies
1 Like
Issue DHCP clients report that a duplicate IP address is detected on the network. If a different device on the same subnet tries to ping that IP address, given out by the DHCP server, they may or may not get a response. Performing an ARP, should show the MAC address of the device answering the ARP request. If this MAC address corresponds to the Palo Alto Networks firewall, then the firewall is the source of the issue. Resolution This condition is fairly common when NAT is configured incorrectly.  Make sure the subnet mask for the translated address is correct. A 24-bit mask will cause the Palo Alto Networks firewall to PROXY ARP for all IP addresses in that range. There has also been an incident where the migration tool converted a Cisco ASA NAT rule into a problem. Source address = x.x.x.x/24 Source translated = x.x.x.x/24 Every device connecting to x.x.x.0 would immediately report a "Duplicate MAC address detected" error. Performing the following command from a DOS prompt on the machine will show the MAC address of the Palo Alto Networks firewall interface responding to the ARP: > arp -s owner: skrall
View full article
skrall ‎01-15-2014 04:38 PM
10,296 Views
0 Replies
Issue When internal servers are configured with static bi-directional NAT addresses, some servers are unable to communicate with each other via their public IP addresses. This is expected behavior due to how policies are evaluated on the Palo Alto Networks devices. This document proposes an alternative configuration as a workaround. Cause Palo Alto Networks firewalls evaluate NAT policies in a top-down fashion. When a rule is matched, that rule is selected to process the packets and no further lookup is performed. To understand how this behavior affects the connectivity to servers, consider the scenario below: Srv A: Private IP = 192.168.89.206, Public IP = 10.66.25.101, FQDN = myserverA.com Srv B: Private IP = 192.168.89.210, Public IP = 10.66.25.102, FQDN = myserverB.com Srv C: Private IP = 192.168.89.209, Public IP = 10.66.25.103, FQDN = myserverC.com Communication should not be a problem for the three servers if they communicate through their respective private IP addresses. The issue occurs if each server only knows of the other servers' Public IP addresses or FQDN names, and each of the servers has a static bi-directional NAT policy. For each of the bi-directional NAT statements written, there are 2 policies created in the dataplane: One for the source NAT One for the destination NAT These NAT policies are arranged in the order that you have configured them, and so configuring bi-NAT1, bi-NAT2 and bi-NAT3 for the three servers will appear in running configuration in the following order: bi-NAT1(s_NAT1) bi-NAT1(dNAT1) bi-NAT2(s_NAT2) bi-NAT2(dNAT2) bi-NAT3(s_NAT3) bi-NAT3(dNAT3) Below is a snippet of the NAT policies configured on the GUI and how the bi-NAT1 appears in CLI. Note: bi-NAT2 and bi-NAT3 CLI outputs are further below but not shown in this example. To view the full NAT policies in dataplane, issue the 'show running nat-policy' command in CLI. With this configuration, when traffic is sourced from Srv_A (192.168.89.206), going to destination myserverB.com (10.66.25.102), the bi-NAT1(s_NAT1) gets matched due to the top-down policy evaluation but the communication never works. The resulting traffic appears as follows: When traffic is sourced from Srv_C (192.168.89.209), however, going to the same destination myserverB.com (10.66.25.102), note that the communication is successful because the correct destination NAT bi-NAT2(dNAT2) gets matched. The logic finds a match for the destination IP and only that IP gets translated. The resulting traffic appears as follows: Notice also that for the working translation, the from-Zone and to-Zone are both trust-L3 (which is correct). For the non-working translation, however, the from-Zone is trust-L3 and the to-Zone is untrust-L3, and Srv_B never receives the ping packet. Resolution To ensure that the servers communicate with each other via their public IP addresses, we need to write distinct destination and source NAT statements for each server, and then position those destination NATs above the source NATs. Note that the destination NAT statements should have the Source Zone set to 'any' to permit incoming traffic from any zone. The following is how the NAT statements look after they have been re-configured: Also, verify that Srv_A can successfully communicate with all internal servers. owner: tasonibare
View full article
tasonibare ‎08-23-2013 08:14 PM
4,273 Views
0 Replies
Overview The maximum number of (Port Address Translation) PAT translations per NAT source IP is 65536. However, running the following show session command may show a number greater than 65536: > show session all filter nat-rule <rule name> count yes Number of sessions that match filter: 83298. Details The PA-5000 Series Firewall can reuse each available source port (up to 8 times for PA-5050 and PA-5060, up to 4 times for PA-5020). This is called DIPP oversubscription. The firewall can use 63k source ports since the available port range is roughly 1k-64k. The allocated ports can support up to 8 (4 on PA-5020) sessions, if they are destined to unique hosts. owner: shasnain
View full article
shasnain ‎08-20-2013 07:05 AM
7,726 Views
3 Replies
Overview Following are available source address translation types and the typical use case for each. Dynamic IP and Port For a given source IP address, the Palo Alto Networks firewall translates the source IP address or range to a single IP address. The mapping is based on source port, so multiple source IPs can share a single translated address until the source ports have been exhausted. This is typical when only having a single public IP address to be shared among many private IP addresses. It is common to choose the IP address assigned to the interface connecting to your ISP: To add more IP addresses to the outbound pool, change the address type to "Translated Address" and add a valid public IP to the list. The firewall will load balance from the address pool based on each session. Use the following CLI command to check the NAT pool utilization: > show running global-ippool Dynamic IP For a given source IP address, the firewall translates the source IP to an IP in the defined pool or range. The mapping is not port based, which makes this a one-to-one mapping as long as the session lasts. Each concurrent session uses an address from the pool, making it unavailable to other source IPs. Be aware when using this option, because the translated pool of addresses can be exhausted if the number of internal hosts concurrently creating outbound sessions exceeds the number of IP addresses in the dynamic pool. This option is used when there are two or more public IPs from the ISP, but not enough to allocate one to each internal host on the network, and you want to assign them to outbound hosts only as needed. It is common to assign a range of IP addresses to the dynamic pool: To view the current NAT pool mappings for a given NAT policy, run the following CLI command: > show running nat-rule-ippool rule <NAT rule name> Static IP Use this translation type to translate a single source address to a specific public address. This is typically used to expose a server (email, web or any application) externally using a translated address that will not change. Selecting "Yes" for Bi-directional creates mapping in both directions based on the source\destination zones that are specified. If Bi-directional is set to No, then the mapping is created based only on the direction of the source\destination zones. Static NAT policies for publicly exposed servers usually have Bi-directional set to Yes, so the outbound traffic for the server uses the same address as inbound traffic: Use the Static IP mapping type to translate an entire address range to a specific address range, a one-to-one mapping. The number of source IPs using this policy must exactly match the translated range. This is typically used to resolve overlapping IP ranges when merging networks. The policy shown here translates all source addresses with at 10.20.1.x address destined to the Corp Zone to a matching address in the 10.30.1.x range: owner: jteetsel
View full article
jteetsel ‎04-03-2013 11:55 AM
63,079 Views
12 Replies
1 Like
Symptoms A loopback interface was configured with a public IP addres to be used to connect to the management interface as the VSYS shared gateway is also used in destination NAT rules. Port 443 is redirected to internal web servers so attempting to create a management profile for that IP address would cause conflicts. When attempting to connect to the loopback's IP address, the connection does not work. Issue When a firewall is configured with a VSYS shared gateway, it is not possible to specify a source zone for address translation rules. Trying to access the management GUI by connecting to a loopback interface configured with a public IP does not work because the connection will hit the outbound NAT rule and will translate the packet to the shared gateway's IP address. Resolution Create the following NAT rule and place it at the top of the NAT policy Source: Untrust zone Destination: Untrust zone Destination IP: Loopback IP address Translated packet: None owner: jteetsel
View full article
npare ‎10-03-2012 03:20 PM
3,207 Views
0 Replies
Symptoms XBox or Playstation games & applications are not able to connect to Xbox Live/PlayStationNetwork due to strict NAT being detected Issue When connecting to the Xbox Live service or PlayStation Network the console establishes client connections to the service.  When hosting some games, or using some applications, a connection from the Xbox Live service or PlayStation Network inbound to the console is required. If these inbound connections can not be established then the console will report that strict NAT has been detected. The consoles are compatible with uPnP devices to allow dynamic opening of TCP and UDP ports to forward traffic required for connectivity to the service. uPnP-enabled routers allow port forwarding to be configured on the device dynamically based on requests coming from internal devices. In a uPnP environment, the console will request the appropriate ports be forwarded to allow the traffic. Palo Alto Networks firewalls are not compatible with uPnP.  Requests from a console via uPnP to open ports will be ignored by the firewall. A 1-to-1 static NAT mapping must be created to forward the appropriate ports to the console from the Xbox Live service or PSN. Further information on how the Xbox360 uses uPnP with NAT can be found here. Resolution Create a static NAT entry to forward all external traffic destined to a particular public IP to the private IP of the console. Each console behind the firewall will require a public IP and an appropriate NAT mapping. For information on how to configure a static 1-to-1 destination NAT policy, or bi-directional NAT mapping please refer to the Understanding PAN-OS NAT document. owner: kfindlen
View full article
kfindlen ‎09-10-2012 12:55 PM
26,509 Views
20 Replies
Symptoms When using a source NAT with dynamic-IP allocation, an error response is received on some Web portal links. In this specific case the user was able to login to the PAN Support Portal, but received the following error when attempting the link to KnowledgePoint. This issue can also occur with websites that go from HTTP to HTTPS. Cause This issue will occur when accessing websites that keep track of the source IP address of the connection. If part of the website was loaded with one public IP, while the rest was loaded using a different public IP address, this might cause the server to lose track of the session and return an error. Resolution Configuring the firewall to NAT using a single IP address will resolve this issue. The following command can be used to force the same public IP address for all the connections (originating from the same source IP address). To enable this feature: > configure # set setting nat reserve-ip yes # set setting nat reserve-time (choose time value) <1-604800> reserve time value in seconds Commit the change owner: panagent
View full article
nrice ‎03-08-2010 10:33 AM
2,817 Views
0 Replies
1 Like
Ask Questions Get Answers Join the Live Community