Configuration Articles

Featured Article
Issue There are instances where we want to source NAT IP addresses to a pool of addresses (Dynamic Pool) and not perform IP and port translations (Dynamic IP and port). The Source NAT would work fine with no traffic issues for the originating sources, until the IP pool is exhausted (no more IP's available to use for NAT). After the pool is exhausted, any session for a new originating source will not be established and this will cause packet drops for this new traffic.   Resolution PAN-OS has a feature called "Fallback Dynamic IP translation" to help resolve this issue. Use this option to create a fall back pool that will perform IP and port translation and will be used if the primary pool runs out of addresses. Addresses can be defined for the pool by using the Translated Address option or the Interface Address option, which is for interfaces that receive an IP address dynamically. When creating a fall back pool, make sure addresses do not overlap with addresses in the primary pool.*   Steps The fallback translating method can be configured to use an alternate way to translate the source IP addresses for the new originating sources, once the pool is exhausted. The fallback is configured under the "Advanced (Dynamic IP/Port Fallback) setting, as follows: Go to the Translated Packet tab of the NAT policy rule. Select "Translated Address" in the drop-down under "Advanced (Dynamic IP/Port Fallback)". Configure another address pool for Dynamic IP. Select "Interface Address" in the drop-down under "Advanced (Dynamic IP/Port Fallback)" Configure Interface-based port translation (Dynamic IP and Port ) Note: When creating a fall back pool, make sure addresses do not overlap with addresses in the primary pool.   *Sourced from the Help Guide > Policies and Security Profiles > Table 148. NAT Rule Settings (Translated Packet Tab)   owner: kprakash
View full article
kprakash ‎09-24-2018 02:34 PM
4,865 Views
0 Replies
1 Like
Although it is not possible to change the port GlobalProtect uses, it is possible to use another port with help from a loopback IP address and security rules.   Here is how to do that: Create a loopback   Make sure the untrust interface can ping the loopback. Assign the loopback as the portal address and the gateway address     In the GlobalProtect Portal > Agent > External tab, set the external gateway to address (10.30.6.56:7000 for example)   Create a Destination NAT rule with service:7000 to 10.30.6.56 (Untrust Interface) translating to 10.10.10.1 (loopback) on service:443 Create a security policy with destination address as the untrust interface and services as 7000 and 443 With this configuration, you will be able to access the global protect portal page on https://10.30.6.56:7000 which will translate to https://10.10.10.1 .Download and install the GlobalProtect client software.   Use the credentials in the username & password fields. In the portal field, use the IP as 10.30.6.56:7000 as shown.             owner: mvenkatesan
View full article
mvenkatesan ‎07-19-2018 06:07 AM
49,422 Views
17 Replies
4 Likes
Overview This document describes how to configure NAT64 on a Palo Alto Networks firewall.   Details NAT64 enables IPv6 hosts to communicate with IPv4 hosts. A NAT64 equivalent address for an IPv4 destination is formed by combining the 32 bit IPv4 address with the Well-Known Prefix 64:ff9b::/n for NAT64 as outlined in RFC 6052.   This implementation needs a DNS64 server that the IPv6 client can communicate with to synthesize AAAA records from A records. The DNS64 server is responsible for doing an IPv4 lookup for the destination and then returning an equivalent IPv6 address (AAAA) to the client by appending the well known prefix. The client then sends the packet with: Src IP = Configured IPv6 address Dst IP = IPv4 embedded IPv6 address returned by DNS64 server When the firewall receives this packet, both the Src IP and Dst IP are translated into IPv4 addresses.          Note:    Though this example shows how to implement NAT64 with a DNS64 server, the firewall is capable of performing the translation from IPv6 to IPv4 regardless of if this was done by a DNS64 server or by some other method, as long as the IPv4 address is embedded into the IPv6 address as described below.               Note: The NAT64 feature supports RFC6052 compatible prefix, which covers Well-Known Prefix and network-specific prefix (For example: all or a part of the customer's global address prefix). This document explains the scenario of Well-Known Prefix with 96.  This can apply to Network-SpecifIc Prefix as well. The following table is the mapping rule from IPv6 to IPv4. The mapping varies with the length of prefix:   Steps The following network topology is used for the configuration example: Bind 9 was used as the DNS64 server for this setup. The following configuration needs to be added to the /etc/bind/named.conf.options file. options { dns64 64:ff9b::/96 { }; listen-on-v6 { any; }; allow-query { any; }; }; Assign the 64:ff9b::/96 network to the interface assigned to 'Untrust' zone. This is to ensure that zone lookups for destination IPs in this network matches the Untrust Zone. Configure the NAT64 rule as follows: On the client, open a browser and try to navigate to a website. We will use www.w3schools.com an example site. The website www.w3schools.com resolves to 66.29.212.73 When the PC does a AAAA record lookup for the hostname www.w3schools.com, the DNS64 server returns the IP address as: 64:ff9b::421d:d449 where 421d:d449 is the hex equivalent of 66.29.212.73.   Verification Check the sessions on the firewall for the DNS and the following web browsing sessions: DNS session:         c2s flow:                 source:      2005:db4:40:0:0:0:0:31 [trust-L3]                 dst:         2005:db4:31:0:0:0:0:200                 proto:       17                 sport:       58674           dport:      53                 state:       ACTIVE          type:       FLOW                 src user:    unknown                 dst user:    unknown           s2c flow:                 source:      2005:db4:31:0:0:0:0:200 [untrust-L3]                 dst:         2005:db4:40:0:0:0:0:31                 proto:       17                 sport:       53              dport:      58674                 state:       ACTIVE          type:       FLOW                 src user:    unknown                 dst user:    unknown           start time                    : Wed Nov 13 13:04:31 2013         timeout                       : 30 sec         time to live                  : 15 sec         total byte count(c2s)         : 100         total byte count(s2c)         : 524         layer7 packet count(c2s)      : 1         layer7 packet count(s2c)      : 1         vsys                          : vsys1         application                   : dns         rule                          : allow_all         session to be logged at end   : True         session in session ager       : True         session synced from HA peer   : False         layer7 processing             : enabled         URL filtering enabled         : False         session via syn-cookies       : False         session terminated on host    : False         session traverses tunnel      : False         captive portal session        : False         ingress interface             : ethernet1/4         egress interface              : ethernet1/3         session QoS rule              : N/A (class 4)   Web Browsing session:         c2s flow:        ( Notice IPv6 addresses in c2s flow )                 source:      2005:db4:40:0:0:0:0:31 [trust-L3]                 dst:         64:ff9b:0:0:0:0:421d:d449                 proto:       6                 sport:       49381           dport:      80                 state:       ACTIVE          type:       FLOW                 src user:    unknown                 dst user:    unknown           s2c flow:       (Notice IPv4 addresses in s2c flow )                 source:      66.29.212.73 [untrust-L3]            dst:     10.66.24.80                 proto:       6                 sport:       80              dport:      65144                 state:       ACTIVE          type:       FLOW                 src user:    unknown                 dst user:    unknown           start time                    : Wed Nov 13 13:04:31 2013         timeout                       : 3600 sec         time to live                  : 3568 sec         total byte count(c2s)         : 758         total byte count(s2c)         : 5439         layer7 packet count(c2s)      : 6         layer7 packet count(s2c)      : 6         vsys                          : vsys1         application                   : web-browsing         rule                          : allow_all         session to be logged at end   : True         session in session ager       : True         session synced from HA peer   : False         address/port translation      : source + destination         nat-rule                      : nat6_4(vsys1)      <<<< NAT64 rule is applied         layer7 processing             : enabled         URL filtering enabled         : False         session via syn-cookies       : False         session terminated on host    : False         session traverses tunnel      : False         captive portal session        : False         ingress interface             : ethernet1/4         egress interface              : ethernet1/3         session QoS rule              : N/A (class 4)   Troubleshooting The following command can be used to view counters for NAT64 at the drop/warn level: > show counter global filter value all | match nat64   Example: click to enlarge   Note: IPv6 firewalling needs to be enabled under Device > Setup > Session > Ipv6 Firewalling.   owner: achitwadgi
View full article
kadak ‎05-09-2018 10:21 AM
32,664 Views
1 Reply
1 Like
Overview “U-turn” refers to the logical path traffic appears to travel when accessing an internal resource when the external address are resolved. U-turn NAT refers to a network where internal users need to access an internal server using the server’s external public IP address.     Details For this example, an internal web server uses a DNS record pointing to the server’s external public Internet address.   External users resolve the address, connect to the external interface of the firewall and their session is translated and handled by the firewall. An internal user connecting to this same FQDN connects to the external address, though the physical server may be located on that user’s internal subnet or a DMZ with internal addressing.   When setting up NAT rules, the source and destination zones need to be configured to correspond to the zones to which the source and destination IP addresses belong. In contrast, security rule zones are determined by the actual source and destination but list the original packet destination IP addresses.   For normal inbound traffic from the Internet to the Web server, the rules look like this: The normal inbound NAT and Security rule that allows external users to access a web-server from the Internet is as follows: Note: Set services to "any" if the user does not want to limit the security policy to ports 80 or 443, or to application default if the user wants it to be used for port 80 only, according to the application web-browsing.   Following is an example of the U-turn NAT rules and Security for Hosts and Web Servers in the Same Zone as host on the LAN: NAT rule for same zone U-turn NAT. No Security Rule is necessary since the traffic's source zone is ultimately destined for the same zone.   This is an example of the U-turn NAT and Security for Hosts and Web Servers in a Different Zone: The NAT rule for Different zone U-Turn NAT is different from the same zone NAT, as there is no need for source nat (there will not be assymetry in the flow of packets), but this rule does need to be placed above the generic outbound hide-NAT: Security Rules for U-Turn NAT:   Additional NAT resources: Getting Started: Network Address Translation (NAT)   owner: tpiens
View full article
nrice ‎08-23-2017 11:54 PM
101,639 Views
27 Replies
6 Likes
Details Palo Alto Networks firewall provides NAT (Network Address Translation) ALG support for the following protocols: FTP H.225 H.248 MGCP MySQL Oracle/SQLNet/TNS RPC RSH RTSP SCCP SIP UNIStim  owner: gbogojevic  
View full article
gbogojevic ‎02-28-2017 02:11 PM
8,081 Views
0 Replies
4 Likes
Overview The ability to disable SIP ALG was introduced in PAN-OS 6.0. SIP ALG performs NAT on the payload and opens dynamic pinholes for media ports. This may cause issues for some SIP implementations. This document describes how to disable SIP ALG. Note: The option to disable SIP ALG is available on the Palo Alto Networks firewall and is a device-wide option. This feature is not supported on Panorama.   Steps Inside of the WebGUI Disabling this feature will prevent the firewall from translating the payload. Go to Objects > Applications and perform a search for the SIP application, as shown below: Open the SIP application. The ALG setting can be seen in the Options section at the lower right area of the display. Click on Customize to bring up the settings dialog and check Disable ALG:   On the CLI Use the following command to disable the SIP ALG : > configure # set shared alg -override application sip alg -disabled yes|no   If issues still occur with SIP after disabling the ALG, testing can be performed setting up filters with packet captures and running the following CLI commands to gather additional information: > debug dataplane packet- diag set : log feature flow basic log feature ctd basic   Note: Not all phone system implementations use the SIP application. In some cases, vendors like Cisco will use applications such as RTP and RTCP. In these cases, if the phones are experiencing issues it might be necessary to perform an application override for the specific phone traffic.   For more information see :  How to Create an Application Override   owner : rvanderveken
View full article
rvanderveken ‎12-19-2016 01:19 PM
54,630 Views
9 Replies
3 Likes
This document describes how to create and view NAT rules on the CLI (command line interface).     Use the following command to create a NAT rule on the CLI: # set rulebase nat rules <NAT Rule Name> description <Description of NAT rule> from <Source Zone> to <Destination Zone> service <Service Type> source <Source IP Address>  destination <Destination IP address> source-translation <Type of Source Translation> interface-address interface <Interface Port number>   The example below create static NAT translation with dynamic IP and port and uses interface ethernet1/4. > configure # set rulebase nat rules StaticNAT description staticNAT from DMZ to L3-Untrust service any source any destination any source-translation dynamic-ip-and-port interface-address interface ethernet1/4 # commit # exit   Once committed, use the following command to confirm creation of the NAT rule. > show running nat-policy   StaticNAT {         from DMZ;         source any;         to L3-Untrust;         to-interface  ;         destination any;         service  any/any/any;         translate-to "src: ethernet1/4 10.46.40.56 (dynamic-ip-and-port) (pool idx: 2)";         terminal no; }   owner: rupalekar
View full article
rupalekar ‎07-25-2016 12:26 PM
21,929 Views
10 Replies
A client (192.168.69.10) in the VPN Zone needs to access a server on the DMZ with a public IP address (204.68.184.237) not configured on the device. The device should translate the public IP to the private IP of the server (172.25.3.50).  The packet should be seen as sourced from an unknown IP (192.168.222.16), which is not configured on the device. The server should be able to initiate the traffic to the client at IP 192.168.222.16 , which will be translated by the device to the client's original IP, 192.168.69.10. Additionally, the source IP of the server should be changed to the Public IP, 204.68.184.237.   Create 2 loopback interfaces: loopback.1: 192.168.222.16/32 with zone "VPN" and appropriate VR loopback.2: 204.68.184.237/32 with zone "VPN" and appropriate VR Create 2 NAT rules: From VPN Client to Server: Source Zone: VPN Destination Zone: VPN Source Address: 192.168.69.10 Destination Address: 204.68.184.237 Source Translation: Select "Dynamic IP and Port". Select "Interface Address" . Select "loopback.1", Select IP "192.168.222.16" Destination Translation: 172.25.3.50 From Server to VPN Client: Source Zone: DMZ Destination Zone: VPN Source Address: 172.25.3.50 Destination Address: 192.168.222.16 Source Translation: Select Dynamic IP and Port.  Select Interface Address. Select loopback.2.  Select IP 204.68.184.237. Destination Translation: 192.168.69.10 Create 2 Security Policies: From VPN Client to Server: Source Zone: VPN Destination Zone: DMZ Source Address: 192.168.69.10 Destination Address: 204.68.184.237 From Server to VPN Client: Source Zone: DMZ Destination Zone: VPN Source Address: 172.25.3.50 Destination Address: 192.168.222.16   owner: kalavi
View full article
panagent ‎04-25-2016 03:37 PM
14,885 Views
2 Replies
2 Likes
Issue The Palo Alto Networks firewall drops any inbound packets destined for a public IP that doesn't exist on the device or have a route for it in the Virtual Router. Configuring Network Address Translation (NAT) for an IP address that doesn't exist on any interface on the firewall requires an extra step.   Note: For this scenario, it is assumed that there is a route for the specified IP address to perform for NAT that points to the firewall's untrust interface. This is normally handled by an upstream device or by the ISP, and ensures that the return traffic returns properly to the firewall's untrust interface.   Resolution There are three possible solutions for this issue: Configure a route for the destination IP to go through untrust interface. Network > Virtual Routers > choose the virtual router Name > Static Routes Add a new route: Why configure the false route? When the packet arrives on the Palo Alto Network firewall, a Layer 3 lookup is done. The NAT takes place when the L3 address is resolved, If a Destination NAT is configured, then another L3 lookup is performed (as the destination has changed) and finally the policy lookup is done. If a packet arrives for a destination that's not on the Palo Alto Network firewall, and there's no route for it, it'll be dropped. Configuring the false route prevents this from happening. Create a secondary IP address on the network of this new destination NAT IP or the IP itself. Example: If 70.1.1.1/24 is on Ethernet1/3 (Untrust), and destination NAT needs to be configured for 70.1.2.22, add either the IP address 70.1.2.22/32, or an IP in the network (70.1.2.1/24 for example) as a secondary IP on the Untrust interface. This will tell the firewall that this network exists on this firewall, and it will know how to route traffic properly. You can also apply the IP address to a Loopback interface, as this will accomplish the same function as adding a secondary IP on an interface.   NAT Rules Configuration Bi-directional NAT: Configure a false route for that IP to go through the Untrust interface. NAT details Source Zone: Trust Dest Zone: Untrust Source IP: Private IP Dest IP: Public IP (which is not under the Untrust subnet)   Destination NAT: Configure a false route for that IP to go through the Untrust interface. NAT details Source Zone: Untrust Dest Zone: Untrust Dest IP: Public IP Dest Translation: Private IP   owner: jdelio
View full article
‎10-21-2015 12:06 PM
26,629 Views
14 Replies
Issue The Palo Alto firewall is configured with two interfaces (Untrust and Web-untrust) connected to the same VLAN on a DMZ switch (running VRRP) and bi-directional static NAT's are configured from Trust to Untrust zones. Whenever the firewall is rebooted, the Palo Alto Networks ARPs for some of the NAT addresses using the Web-Untrust MAC address, despite NAT rules that specify Trust to Untrust.  Removing the bi-directional flag and manually creating the inbound portion of the  NAT rule from Trust to Untrust resolves the problem.   Resolution Bi-directional NAT rules were created to simplify the configuration of NAT rules for servers that must be able to initiate outbound sessions (where the source address is translated  and also respond to inbound sessions (where the destination address is translated on incoming packets). For inbound sessions,  bi-directional NAT rules must be able to match connections coming in from internal OR external zones. This requirement stems from the fact that many companies utilize a single DNS entry for services provided to internal users and external users. Because of this requirement, the bi-directional NAT rule will create a static source NAT rule that exactly contains the match criteria specified in the NAT rule (for outbound sessions). It will also create a NAT rule (one that is not shown in the config) to handle destination NAT (for inbound sessions). This rule uses a source zone of 'ANY' so that traffic from internal users (internal zone) and traffic from external users (external zone) will match the NAT rule and may therefore utilize the services offered by that server.   In this particular case, the Palo Alto device is using ARP on the Web-Untrust interface because that interface can be used to access the server being serviced by the bi-directional NAT rule. This is true because the Untrust and Web-Untrust interfaces are on the same subnet. The destination NAT rule automatically created has a source zone of 'ANY' for the reasons described above. If  the configuration were changed to be using two separate NAT rules (one for source NAT for outbound sessions and another for destination NAT for inbound sessions) this problem can be avoided. If the destination NAT rule has a source zone that excludes Web-Untrust, the firewall will no longer ARP for the NAT'ed address on the Web-Untrust interface.   owner:  jnguyen
View full article
nrice ‎09-09-2015 10:20 AM
15,397 Views
5 Replies
Details   By connecting different sites to MPLS WANs, companies can provide convenient internal network connectivity between sites.  Often, the MPLS routers deployed are connected to the internal network through the firewall, providing visibility and control for the traffic passing across the MPLS.  How the Palo Alto Networks firewall is configured is an important aspect in determining what traffic is allowed to pass to or from the MPLS cloud. It is important to remember that the Palo Alto Networks firewalls are not MPLS routers, but can serve as a logical connection point to the MPLS cloud by being connected to the MPLS router that terminates MPLS at the site.   Example network topology:   Recommendations   Zones To control and monitor traffic passing across the MPLS cloud, it's important to assign the Ethernet interface connecting to the MPLS router to a different zone than the other interfaces. It will be easier to later define security policies which allow traffic to or from the MPLS zone and also to or from the other internal zones. In this scenario, traffic logs can be available for the security policies that are created between the zones. If the interface connecting to the MPLS cloud is in the same zone as the trust for example, then by default traffic between MPLS networks and trust networks will be allowed and not logged unless there's an explicit security policy denying traffic to and from the trust zone.     Routes The firewall requires routes for every network at the sites across the MPLS. This can be accomplished by configuring static routes for those networks with the next hop IP address as the MPLS router's IP address. Another possibility is deploying dynamic routing on the routers at each site if there are many networks and many sites.                                                                                            Security Policies If full connectivity between the sites is necessary or desired in initial setup, then two allow policies can be created; one for the MPLS zone to reach the internal zones and one for the internal zones to reach the MPLS zone.  Depending on what access is needed across the sites, then the security policies can be restricted to only allow what is necessary.      NAT Policies No NAT policies need to be configured since typically there is no need to translate the private address ranges because the WAN enables private networks from one site to reach the private networks at the other site.  If however there appears to be overlapping subnets at two sites then NAT can be employed to hide the addresses at one end by mapping them to a unique subnet.  A similar technique is used with IPSEC VPN tunnels and that is documented in How to Use NAT in an IPSEC VPN Tunnel.  The subnet whose addresses are mapped can only be accessed from that point using the mapped addresses, so keep in mind the implications for accessing servers and referencing any DNS records.   Note: Typically, the local MPLS router needs to have routes to reach the remote sites networks. Also, the remote site needs to have routes in place to reach the local site. If there is a firewall in place at the remote site, its policies will similarly need to allow the traffic through.   owner: astanton
View full article
astanton ‎08-28-2015 03:47 PM
10,884 Views
0 Replies
3 Likes
Issue In this configuration, the Palo Alto Networks device responds to an ARP reply from two different interfaces for the same IP. For Destination NAT, only the source zone and original un-translated IP address are checked to see if the parameters match the NAT rule.   Cause There is no check to see if the destination zone matches the rule since it will require an extra route lookup. If both zone interfaces can receive the ARP request, then both will respond with ARP reply.   Workaround The workaround for this issue is to replace the bi-directional NAT rule with separate Source and Destination NAT rules. In the Destination NAT rule, the source zone needs to be explicitly specified.   See Also What does the Bi-Directional NAT Feature Provide?   owner: ggutierrez
View full article
ggutierrez ‎08-27-2015 11:04 AM
6,953 Views
0 Replies
2 Likes
Overview The Dynamic IP and Port (DIPP) translation is dedicated to TCP and UDP related traffic only, and not to other IP protocols. The reason is because pure IP protocols, such as ICMP, do not use a L4 header that contains source and destination ports. On the other hand, ICMP protocol is widely used in networking as a simple connectivity test (either as PING or Traceroute). A common scenario in enterprise networks is that single DIPP translation is used for all LAN to internet traffic, since that approach consumes less IP address space. Therefore, ICMP traffic will also hit the same DIPP NAT policy. Details To translate ICMP traffic, Palo Alto Networks firewall takes the ID and Sequence fields from the ICMP header and treats them the same (internally) as if they were ports. This uses the Identification field as a source port reference and Sequence field as destination port reference. When the ICMP echo reply arrives on the firewall, it is being translated based on the values found in the Sequence and ID field of its ICMP header. DIPP Policy: XP-200 { from Trust; source 192.168.247.0/24; to Untrust; to-interface  ; destination any; service any/any/any; translate-to [ "src: 10.193.16.241 (dynamic-ip-and-port) (pool idx: 8)" "     10.193.16.242 (dynamic-ip-and-port) (pool idx: 8)" ]; terminal no; An example of an ICMP echo request packet sent from host machine (tcpdump): 16:10:44.859384 IP (tos 0x0, ttl 64, id 40874, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.247.248 > 8.8.8.8: ICMP echo request, id 22636, seq 438, length 64 16:10:44.867042 IP (tos 0x0, ttl 49, id 0, offset 0, flags [none], proto ICMP (1), length 84) 8.8.8.8 > 192.168.247.248: ICMP echo reply, id 22636, seq 438, length 64 Session is installed on the firewall for this ICMP traffic: > show session all filter destination 8.8.8.8 protocol 1 source 192.168.247.248 ------------------------------------------------------------------------------------------------------------------------------------ ID     Application State  Type Flag Src[Sport]/Zone/Proto (translated IP[Port])           Vsys Dst[Dport]/Zone (translated IP[Port]) ------------------------------------------------------------------------------------------------------------------------------------ 240674 ping        ACTIVE FLOW NS   192.168.247.248[22636]/Trust/1 (10.193.16.241(22636]) vsys1 8.8.8.8[438]/Untrust  (8.8.8.8[438]) Session is being translated using Identification and Sequence fields from the ICMP header: > show session id 240674 Session 240674 c2s flow: source:      192.168.247.248 [Trust] dst:         8.8.8.8 proto:       1 sport:       22636 dport:      438 state: INIT type:       FLOW src user:    unknown dst user:    unknown s2c flow: source:      8.8.8.8 [Untrust] dst:         10.193.16.241 proto:       1 sport:       438 dport:      22636 state: INIT  type:       FLOW src user:    unknown dst user:    unknown start time : Wed May 14 17:13:02 2014 timeout : 6 sec total byte count(c2s)         : 98 total byte count(s2c)         : 98 layer7 packet count(c2s)      : 1 layer7 packet count(s2c)      : 1 vsys : vsys1 application : ping rule : ANY-ANY session to be logged at end   : True session in session ager       : False session synced from HA peer   : False address/port translation      : source + destination nat-rule : XP-200(vsys1) layer7 processing : enabled URL filtering enabled         : False session via syn-cookies       : False session terminated on host    : False session traverses tunnel      : False captive portal session        : False ingress interface : ethernet1/2 egress interface : ethernet1/3 session QoS rule : N/A (class 4) tracker stage firewall        : Aged out Since ICMP Identifier and Sequence numbers are both 16 bits long, limitation in terms of number of translations per IP is the same as for TCP/UDP traffic, which means 65535 for source and 65535 for destination NAT. Also, limitation in terms of number of NAT DIPP policies applied to UDP/TCP traffic applies to ICMP traffic as well since they share the same memory space. owner: djoksimovic
View full article
djoksimovic ‎05-16-2014 08:49 AM
10,082 Views
0 Replies
Overview This document describes how to make the required configuration changes for GlobalProtect when a Palo Alto Networks device with a private IP address on the untrust interface is being NATed by an upstream device with a public IP address. Example scenario: PAN Eth1/3 192.168.1.1 (Private IP) with a Static NAT on the upstream device of 1.1.1.1 (Public IP) Steps The following steps applies the IP addresses from the example scenario described above. Generate Portal and Gateway server certificates with the Common Name configured for the Public IP address: FQDN that resolve to 1.1.1.1 or IP address of 1.1.1.1 as Common Name. To setup the GlobalProtect Portal go to Network > GlobalProtect > Portal > Portal Configuration and use the untrust interface Eth1/3 and Private IP address assigned to interface. Select the Server Certificate with the Public IP address for Common Name. Configure Client Configuration Gateway IP address to the Public IP address Network > GlobalProtect > Portal > Client Configuration > Add > Gateway > External Gateways > Add The portal will send the GW IP address that the client will connect to and it will need to be the NAT Public IP address, which is this example: 1.1.1.1. To configure the GlobalProtect Gateway go to Network > GlobalProtect > Gateway > Add and use the untrust interface Eth1/3 and Private IP address assigned to interface. owner: gcapuno
View full article
gcapuno ‎04-16-2014 12:36 AM
5,363 Views
0 Replies
Overview This document explains how to configure a Palo Alto Networks firewall that has a dual ISP connection in combination with GlobalProtect VPN. One ISP link is used for non VPN traffic and the other is used exclusively for GlobalProtect VPN traffic. Configuration Goals: Dual ISP connection in combination with VPN tunnels. Simple Global Protect VPN Gateway/Portal and Client 1 ISP is preferred for LAN to Internet traffic - Default route towards ISP1 Other ISP link used for GP VPN traffic Details ISP1 is used as the primary ISP.  ISP2 is the GlobalProtect VPN traffic ISP. Palo Alto Networks firewall version: 5.0.6 ( Any version >= 4.1.x can be used ) Interface Configuration Configure four interfaces: Ethernet 1/1 - 10.193.19.1/23 - LAN Zone Interface Ethernet 1/2 - 192.168.2.11/24 - Zone ISP 1 Interface Ethernet 1/3 - 10.193.17.1/23 - Zone ISP 2 Interface tunnel.1 - 172.16.1.1/24 - Zone VPN Interface The VPN Zone GlobalProtect VPN will be configured soon. A requirement for the VPN to function is a tunnel Layer 3 interface. This interface is a virtual interface that has all the features of a physical interface. As such it can be configured in a zone of its own. In this configuration the tunnel.1 interface is placed in the Zone VPN. Whenever VPN traffic is initiated by the customer, this traffic will be seen by the firewall as egress from the tunnel.1 interface and VPN Zone. The VPN traffic needs to reach the ISP2 Zone . Network Security Configuration Configure basic networking and Security Policies to allow traffic between: LAN and ISP1 VPN and ISP2 Add Default Route 0.0.0.0/0 to ISP1: Allow traffic to the 2 ISPs by using NAT Rules In order for the outgoing traffic to be translated from internal IP addresses to outside IP addresses, we need to use some kind of Source NAT. In this example Dynamic IP and Port NAT is being used. The global IP will be the outgoing interface IP. NAT to ISP1: Source zone : any Destination zone: ISP1 NAT Type: Source NAT Source translation : dynamic IP and Port ; Interface : Ethernet 1/2 ; IP address: 192.168.2.11 NAT to ISP2: Source zone : any Destination zone: ISP2 NAT Type: Source NAT Source translation : dynamic IP and Port ; Interface : Ethernet 1/3 ; IP address: 10.193.17.1 At this point, traffic should be able to reach ISP1 from LAN and ISP2 from GlobalProtect VPN that has yet to be configured. ISP1 Connection Test Policy-Based Forwarding Since we are passing the default route 0.0.0.0/0 to the GlobalProtect client, the default behavior of the firewall is to route the packets towards ISP1, because of the default route set up in the static routes of the Virtual Router . The PBF will modify routing behavior in the following way: All packets initiated from interface tunnel.1 that are heading for any other address other than directly connected LAN subnetwork or the directly connected ISP1 subnetwork should be forwarded to interface ethernet 1/3 , going to ISP2. The next hop is the IP pointing to the ISP2 router that goes to the Internet. There is no need for Symetric Return since the NAT will identify NATed sessions and translate it back to the initial internal IP. This will overwrite all packets going to an unknown address originating from the GlobalProtect tunnel interface. GlobalProtect Configuration This implementation of GlobalProtect is a basic one, without any special features. For a more detailed GlobalProtect configuration, check other Knowledge Base articles, Configuration Guides or the official Administration Guide in addition to the following references: How to Configure GlobalProtect How to Generate a New Self-Signed Certificate GlobalProtect Configuration Tech Note GlobalProtect Setup Gateway IP: 10.193.19.1 GlobalProtect Client IP Pool: 172.16.1.2 -> 172.16.1.55 Tunnel Interface: tunnel.1 Tunnel Interface IP: 172.16.1.1 Routes passed to clients : 0.0.0.0/0 - The clients will have as default gateway 172.16.1.1 - tunnel.1 interface Detailed configuration: Certificates GlobalProtect Gateway GlobalProtect Portal Also, the user authentication needs to be configured in the Local Database: Once this is set up, the GlobalProtect Client should be able to connect to the GlobalProtect Gateway: Client Connection to GlobalProtect Connection is successful. Assigned IP address is 172.16.1.2: A Virtual interface is created on the Windows machine: And, the default route is being injected: Connection to Internet through ISP2 is working: Note:  This configuration does not achieve a failover if any one of the ISPs is not reachable. owner: bbolovan
View full article
bbolovan ‎10-15-2013 01:33 AM
73,672 Views
1 Reply
Details To NAT another IP Pool provided by an ISP and allow traffic Set up a loopback interface with an IP from the new IP pool. Set up the loopback interface in the same zone as the external interface. Set up a security policy to allow traffic to loopback interface external IP. Note: The internal logic for Palo Alto Networks firewall is to do a forwarding lookup prior to NAT policy evaluation. Therefore, it is necessary to assign an IP to the loopback interface before the NAT policy can take effect. owner: ukhapre
View full article
panagent ‎01-22-2013 11:28 AM
7,406 Views
0 Replies
1 Like
Overview This document shows a simple configuration of the Symmetric Return or Return to Sender feature in PAN-OS 5.0. Details This feature forwards the packet to the MAC address from where the SYN or lost packet was received.  This ensures return traffic follows the same interface which the session created and is useful in an asymmetric routing or Dual ISP environments. Example: Topology In the above diagram, traffic from the client 5.1.1.1 can reach the internal server 192.168.83.2 via two public IPs 1.1.1.83 and 2.1.1.83.  Both of these public IPs do a destination translation to the internal server.  If traffic arrives at internal server via ISP1 on Ethernet 1/1, then the return traffic is returned via Ethernet 1/1 instead of the default route Etherenet 1/2 as shown in diagram below. NAT INCOMING_NAT-ISP-1 and 2 rules are for translating the public IP address to internal server IP 192.168.83.2. ISP1NAT and ISP2NAT are for outbound traffic when traffic is leaving to the ISP1 and ISP2 respectively. Network Routing The firewall is configured with only one default route going through ISP2. PBF Symmetric return is based on PBF. Create a PBF rule for incoming traffic into the firewall for sending the return traffic from the firewall to the same ingress interface as received. Because symmetric return is based on interfaces, select the Source Type as Interface. Note: Zone is not a valid configuration.  Also, tunnel interface is not valid since there are no mac-address associated with the tunnels. Select the destination IP address as the internal IP address of the server. Configure Next Host IP address if Destination Network is not directly connected. Ethernet 1/6 is selected as the egress interface because the internal server is on the same segment. If internal server is not on same server then, specify next hop to reach in NEXT HOP field. Select the IP address of ISP1 as next hop (1.1.1.84). Verify the symmetric route return is working, run the following commands: > show session id 6149 Session            6149         c2s flow:                 source:      5.1.1.1 [DMZ]                 dst:         1.1.1.83                 proto:       1                 sport:       13812           dport:      3                 state:       INIT            type:       FLOW                 src user:    unknown                 dst user:    unknown                 pbf rule:    ISP1-PBF 1         s2c flow:                 source:      192.168.83.2 [L3-Trust]                 dst:         5.1.1.1                 proto:       1                 sport:       3               dport:      13812                 state:       INIT            type:       FLOW                 src user:    unknown                 dst user:    unknown                 pbf rule:    ISP1-PBF 1                 symmetric return mac: 00:1b:17:05:8c:10         start time                    : Tue Jan  8 16:23:55 2013         timeout                       : 6 sec         total byte count(c2s)         : 98         total byte count(s2c)         : 98         layer7 packet count(c2s)      : 1         layer7 packet count(s2c)      : 1         vsys                          : vsys1         application                   : ping         rule                          : all         session to be logged at end   : True         session in session ager       : False         session synced from HA peer   : False         address/port translation      : source + destination         nat-rule                      : INCOMING_NAT-ISP-1(vsys1)         layer7 processing             : enabled         URL filtering enabled         : False The firewall is matching the PBF rule created. In the output below, you can see the return mac where traffic is being sent. > show pbf return-mac all current pbf configuation version:   0 total return nexthop addresses :    8 index   pbf id  ver  hw address          ip address                      return mac          egress port -------------------------------------------------------------------------------- 7       1       2    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 2       1       0    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 6       1       1    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 8       1       2    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 5       1       1    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 9       1       3    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 1       1       0    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 10      1       3    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1 maximum of ipv4 return mac entries supported :     500 total ipv4 return mac entries in table :           2 total ipv4 return mac entries shown :              2 status: s - static, c - complete, e - expiring, i - incomplete pbf rule        id   ip address      hw address        port         status   ttl -------------------------------------------------------------------------------- ISP1-PBF        1    1.1.1.84        00:1b:17:05:8c:10 ethernet1/1    s      1603 ISP1-PBF        1    5.1.1.1         00:1b:17:05:8c:10 ethernet1/1    c      1800         session via syn-cookies       : False         session terminated on host    : False         session traverses tunnel      : False         captive portal session        : False         ingress interface             : ethernet1/1         egress interface              : ethernet1/6         session QoS rule              : N/A (class 4) owner: sdurga
View full article
sdurga ‎01-07-2013 09:29 PM
48,850 Views
16 Replies
1 Like
In addition to using a non-https Global Protect Portal, you can access an associated Gateway on a configured loopback interface. If you only have one public-facing IP address, and you wish to host SSL-based applications, such as OWA on that IP, the following information provides the configuration steps for doing so. Please follow Knowledge Base article How to Configure GlobalProtect Portal Page to be Accessed on any Port with one caveat. You'll need to create a second loopback interface in addition to the first loopback interface used for the Portal. Create additional loopback interface Make sure the untrust interface can ping the loopback. > ping source 99.7.172.157 host 10.1.1.     PING 10.1.1.2 (10.1.1.2) from 99.7.172.157 : 56(84) bytes of data.     64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.126 ms     64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.068 ms     Assign loopback interface as the Portal address Assign loopback.1 interface as the Gateway address Create the following services and add them to a service group. These services will be natted to our Gateway loopback interface. In this example, services were created destined for ports 500 (ike/ciscovpn), 4501 (ipsec-esp-udp). The two custom services are added in addtion to the predefined service-https to the gateway service group profile. Create the services   Add the services to a service group object Create the security policies as needed. As noted in the prior KB article,  a rule is needed for the Portal page to redirect that traffic on a non-ssl standard port to our first loopback interface. Here GP portal is accessed on port 7000 instead of port 443. Below this rule, another rule is created to the gateway allowing ike, ipsec, panos-global-protect, ssl and web-browsing respectively. Create the NAT policy which will forward traffic to the second loopback (loopback.1) interface. In this example, the gateway service group is utilized and used to forward traffic to 10.1.1.2, the loopback.1 interface previously configured. Configure iPhone/iPad on the Gateway. Enable 'X-Auth Support' on the gateway and create a Group Name and the Group Password respectively. This will be utilized when configuring the VPN profile on the mobile devices. Create the VPN Profile on the iPhone/iPad using the shared secret configured in the previous step. The password in the profile will need to match with the authentication method chosen (ie ldap, kerberos,localdb, etc). Confirm access via your Global Protect client as well as your mobile device. > show global-protect-gateway current-user         GlobalProtect Name : gp-gateway (2 users)         Domain User Name      Computer        Client          Private IP      Public IP      ESP    SSL    Login Time      Logout/Expiration TTL     Inactivity TTL         ------ ---------      ---------      ----------      ---------      ---    ---    ----------      ----------------- ---      ----------- ---               \renato          PAN01347        Windows 7 (Version 6.1 Build 7601 Service Pack 1)10.10.10.2      64.124.57.5    exist  none    Oct.02 06:04:01 Nov.01 06:04:01  2589926  9641               \renato          64.124.57.5    iPhone OS:6.0  10.10.10.1      64.124.57.5    exist  none    Oct.02 06:38:33 Oct.02 07:39:33  3657     10798 owner: rkalugdan
View full article
gswcowboy ‎10-01-2012 10:27 PM
21,987 Views
1 Reply
When creating a Source NAT rule directly on a firewall, it is common to use Interface Address as the NAT type and select an IP attached to that interface as the Source NAT address. When using Panorama, the Interface Address does not provide any interfaces in the drop-down list.  If an interface is typed in the field, the IP address field does not allow a change from None. This is by design, because of the large potential for conflicts (each connected firewall would likely have ethernet1/1, ethernet1/2, etc.) and  of the potential for a very large list. Panorama can support over 100 devices, if licensed to do so, and each firewall can have hundreds of interfaces if sub-interfaces are included. There are two scenarios: The Firewall interface has single IP address defined. In this case, the NAT rule can be configured with Address Type 'Interface Address', enter the interface and leave IP address set to 'None'. When this configuration is pushed to a device, the device will use the first IP address defined on the interface to translate the traffic. Note: This method is only supported on single firewalls and on Active/Passive High Availability (HA) pairs. Active/Active HA does not support this type of nat rule. Apply scenario 2 (below) for Active/Active HA clusters. The Firewall interface has multiple interfaces defined and the translated address desired is not the first defined. In this case, you must select Address Type "Translated Address" and manually enter the desired IP address. owner: gwesson
View full article
gwesson ‎10-01-2012 05:32 PM
4,515 Views
1 Reply
Overview Currently there is no way to redirect traffic bound for all external NTP servers to a single internal server. However, traffic destined to specific external servers can be translated to the address of an internal server using NAT policies. If the server exists on a different zone than that of the hosts that will be accessing it, a simple destination NAT will suffice. However, if the server is on the same network (zone) as the hosts, a "U-Turn" NAT is needed, as shown here: In this example "Public NTP Server" is an address object that contains the IP address of a single public NTP server. The "Private NTP Server" is an address object that contains the address of the private NTP server where traffic should be sent. See Also How to Configure U-Turn NAT owner: jhess
View full article
npare ‎10-01-2012 01:32 PM
5,877 Views
2 Replies
Symptoms Scenario: Trust Zone : 192.168.1.0/24 DMZ Zone : 172.16.1.0/24 Firewall using 192.168.1.1 in the Trust Zone and 172.16.1.1 in the DMZ Zone Workstation at 192.168.1.100 can ping a Server in the DMZ at 172.16.1.100 but cannot ping the Firewall's IP address in the DMZ Zone (172.16.1.1) NAT Rule in place: From Trust to DMZ Any Source IP / Any Destination IP Perform Dynamic Source NAT with the Firewall's IP address of 172.16.1.1 Issue When 192.168.1.100 pings 172.16.1.100, the firewall will translate the packet and the new source IP address will be 172.16.1.1, which means the packet sent on the DMZ Zone will have 172.16.1.1 as source and 172.16.1.100 as destination. This PING will work with no issue. When 192.168.1.100 pings 172.16.1.1, the firewall will translate the packet as well and the new source IP address will be 172.16.1.1, which means that both the packet's source IP and destination IP will be the same (172.16.1.1) and the packet will be discarded. Resolution Create a new NAT rule: Source Zone : Trust, Destination Zone, DMZ Source IP : 192.168.1.0/24, Destination IP : 172.16.1.1/32 No translation Place the new rule above the rule that performs Source NAT Commit changes. owner: nayubi
View full article
npare ‎08-31-2012 10:45 AM
4,510 Views
0 Replies
This document explains how to configure internet access (with destination NAT) using a VSYS and a shared gateway. Assuming the following for this example: SG = Shared Gateway name. SG1 = Shared Gateway virtual system name. Vsys1 and Vsys2 = the two virtual systems that will share the gateway. The default virtual router contains eth1/3 resides in vsys1. We are using bi-directional NATs for inbound\outbound connections for two different web servers that need to have public NATs. Web Server on vsys1 is 192.168.85.80 (internal) 1.1.1.80 (external). Web Server on vsys2 is 192.168.95.81 (internal) 1.1.1.81 (external). The untrusted interface is eth1/3, which is connected to the ISP. This interface has been removed from any zones or NAT policies. The following zones exist: Name Location Type Interface Description trust_vsys1 vsys1 Layer3 eth1/6 trusted for vsys1 systems trust_vsys2 vsys2 Layer3 eth1/9 trusted for vsys2 systems untrust_SG SG1 Layer3 eth1/3 Shared gateway - Internet connection vsys1_SG vsys1 external none connects vsys1 and shared gateway vsys2_SG vsys2 external none connects vsys2 and shared gateway Procedure Create a shared gateway under Device > Shared Gateways and add the internet connecting interface to it. If this interface is already assigned to another virtual system (vsys), you can change the vsys it's assigned to after you create the shared gateway. Create an external zone type in each vsys that includes your shared gateway virtual system, to be the conduit between your internal virtual systems and the shared gateway. Create a Layer 3 zone located in the Shared Gateway vsys for your shared gateway that includes your internet connection interface (eth1/3 in this case). This will be the untrusted or outside zone to be shared between both virtual systems. Create NAT polices for each web server under the shared gateway vsys with the following settings (this policy is not located in the VSYS): Rule Source Zone Destination Zone Source Address Source Translation web-vsys1 any Untrust_SG 192.168.85.80 Static, 1.1.1.80 Bi-Directional yes web-vsys2 any Untrust_SG 192.168.95.81 Static, 1.1.1.81 Bi-Directional yes Under vsys1, create the following security policies, one for outbound connections and one for inbound connections to the web server running behind that vsys The inbound policy must contain both the translated and non-translated address as the destination address: Rule Source Zone Destination Zone Destination Address Application service outbound trust_vsys1 vsys1_SG any any any inbound web vsys1_SG trust_vsys1 192.168.85.80 1.1.1.80 web-browsing service-http Under vsys2, create the following security policies, one for outbound connections and one for inbound connections to the web server running behind that vsys. The inbound policy must contain both the translated and non-translated address as the destination address: Rule Source Zone Destination Zone Destination Address Application service outbound trust_vsys2 Vsys2_SG any any any inbound web Vsys2_SG trust_vsys2 192.168.95.80 1.1.1.80 web-browsing service-http Create a virtual router for Vsys2 that contains the trusted interface for vsys2 (eth1/9) and create the following default route: Destination = 0.0.0.0/0 Next Hop = Next VR and select the name of the virtual router in vsys1 For the virtual router under vsys1, create a route for the trusted network for vsys2: Destination = 192.168.95.0/24 Next Hop = Next VR and select the name of the virtual router in vsys2 owner: jteetsel
View full article
npare ‎07-19-2012 09:38 AM
36,295 Views
1 Reply
1 Like
To configure a rule where multiple new source IP addresses and ports need to be used: Create the NAT Rule Set the following options as Translated Packet Translation Type : Dynamic IP and Port Address Type : Translated Address Enter the list of IP addresses to be used in the Translated Address box. owner: mbutt
View full article
mbutt ‎07-12-2012 01:12 PM
6,710 Views
0 Replies
1 Like
Details When a Palo Alto Networks firewall has access to two or more service providers, creating an inbound NAT rule has to be done differently because of the fact that inbound traffic might come from either ISP. For this example; Public IP address to be used from ISP "A" will be 1.1.1.1 and connected to Ethernet 1/1 Public IP address to be used from ISP "B" will be 2.2.2.2 and connected to Ethernet 1/2 Firewall's default gateway points to ISP "A" A crucial requirement for this scenario is for the server to have two internal IP addresses. 172.16.1.10 and 172.16.1.11 will be used for this example. Another alternative would be to use the symmetric return feature which alleviates the need for multiple IP addresses on the server, reference the following article for more information on configuring symmetric return for the same scenario: How to Configure Symmetric Return NAT Rules Rule Number Source Destination Action 1 Untrusted Zone 1.1.1.1 Translate Destination IP to 172.16.1.10 2 172.16.1.10 Untrusted Zone Translate Source IP to 1.1.1.1 3 Untrusted Zone 2.2.2.2 Translate Destination IP to 172.16.1.11 4 172.16.1.11 Untrusted Zone Translate Source IP to 2.2.2.2 Policy Based Forwarding (PBR) Rule Source Destination Forwarding 172.16.1.11 Untrusted Zone Action : Forwarding Egress Interface : Ethernet 1/2 Next Hop : <ISP "B"s gateway IP> Security Rules Create the necessary rules to allow traffic to/from the server and commit the changes. owner: jteetsel
View full article
npare ‎07-02-2012 01:10 PM
14,410 Views
2 Replies
Performing inbound NAT with a public IP address given by a DHCP server requires a different technique than when a fixed IP address is used. Requirements: Dynamic DNS host (for example, dyn.com) The Dynamic DNS agent service running on a computer on the network To create the NAT rule, go to Original Packet and enter: Source Zone The untrusted zone configured on the outside interface Source Address Any Destination Address Set a new address object and select "FQDN" as type, then enter the dynamic DNS host used owner: dwhyte
View full article
npare ‎06-22-2012 08:46 AM
11,725 Views
3 Replies
Issue: In a topology with two Virtual Routers, VR1 and VR2,  sharing a subnet,  VR1 has a public interface on Ethernet 1/1 (100.1.1.10/24) and VR2 has a public interface on Ethernet 1/2 ( 100.1.1.20/24).  Both use the same ISP Gateway, 100.1.1.1/24. Users  need to access a server on a public IP 100.100.100.100, which resides in a DMZ interface conected to VR2.  The private IP of the server is 10.10.10.10.  Sessions are seen as "incomplete" because Ethernet 1/1 is responding to the ARP requests for 100.100.100.100. Resolution: NAT rules are defined based on the zone configured.   If the untrust zone is shared between two different Virtual Routers, either of them  will respond to the ARP request for 100.100.100.100. In this case, only VR2 should respond to the ARP request.  Do not use the same Untrust Zone  for both of the public interfaces residing on different Virtual Routers. Create a new Untrust Zone, for example "Untrust-VR2", and add the public interface of VR2 to that zone. Configure a Bi-Directional NAT: Source Zone: DMZ Destination Zone: Untrust-VR2 Source Address: 10.10.10.10 Destination Address: Any Destination Interface: Ethernet 1/2 Source Translation: Static IP "100.100.100.100" Bi-Directional: Yes Create the security policy accordingly. Based on this configuration, only VR2 will respond to the ARP request. Owner:  kalavi
View full article
panagent ‎03-04-2012 03:43 PM
7,347 Views
1 Reply
2 Likes
Overview In theory, each source IP can handle 64K sessions. Taking the destination IP address into consideration increases the amount of NAT sessions per IP.  The destination IP is hashed and placed in a "bucket".  In the PAN device, there are "N" number of buckets of 64K ports. "N" is 2 for PA-2000, 4 for PA-4020 and 8 for PA-4050/4060. This is per IP. The NAT supports 16 Mil simultaneous translations.  A single IP address can be source/destination hashed as described, resulting in a potential total of "N times 64K" translations, providing that the destination IP is not the  same. For example, on a PA-4050, a single public IP address can NAT up to 512K (where N=8) translations behind it as long as the destination IP addresses were not the same. owner: snisar
View full article
panagent ‎01-04-2012 04:01 PM
9,111 Views
1 Reply
Details It is possible to configure a Denial-of-Service (DoS) protection policy for a server. In the example below, users from the Internet are accessing the server, 1.1.1.10, which is NATed to 192.168.1.10. The DoS policy will be configured to protect the server with a maximum of 20000 sessions and 1000 connections per source IP. Configure protection for the server (Type aggregate), or use the Zone protection profile. Objects > DoS Protection > Add profile Profile Name = "Session Limit Server" for the example Type Aggregate, Select Syn Flood Resources Protection Select Sessions Max Concurrent Limit is set to 20000   Configure protection from a single IP to server (Type Classified). No Flood protection is needed. Objects > DoS Protection> Add profile Name "SessionLimit SingleIP" for the example Resources Protection Select Sessions Max concurrent Limit = 1000 Configure the DoS Policy for the server. Policies > DoS Protection > Add DoS Rule General tab Name = DoS Server for the example Source tab Zone = Untrust Source Address = Any Source User = any Destination tab Type = Zone Zone= Untrust Destination IP = Server 1.1.1.10 Option/Protection tab Action = Protect Aggregate select "SessionLimit Server" profile from drop down menu Select Classified and "SessionLimit SingleIP" profile from the drop down menu owner: wtam
View full article
nrice ‎02-22-2011 01:15 PM
20,501 Views
14 Replies
3 Likes
Details NAT traversal is required when address translation is performed after encryption. With this option enabled, the firewall will encapsulate IPSEC traffic in UDP packets allowing the next device over to apply address translation to the UDP packet's IP headers. Note: Encapsulating IPSEC in UDP is likely to require an adjustment to the MSS on the firewall and on devices between the firewall and the internet because of the extra headers. Palo Alto Networks firewalls have the option to automatically adjust the MSS. Enabling NAT traversal via the GUI Selecting the "Enable NAT Traversal" checkbox on the IKE Gateway configuration screen. Enabling NAT traversal via the CLI # configure # set network ike gateway <gw name> protocol-common nat-traversal enable no (yes) # commit owner: panagent
View full article
nrice ‎12-15-2010 11:24 AM
21,136 Views
2 Replies
1 Like
Details No NAT rules are configured (at Policies > NAT) by specifying the desired match conditions (zone, IP, etc.) and leaving the source translation and destination translation fields blank. It is also possible to specify a list of IP addresses or IP address ranges in a NAT rule. If No NAT rules were used in the past to  exclude specific IP addresses from a range or subnet defined in another NAT rule, simply define ranges around the excluded address(es). In the following example NAT rule, 1.1.1.1 - 1.1.1.40 and 1.1.1.50 - 1.1.1.254 are excluded. Note: The above No NAT policy should be placed at the appropriate position to ensure it is processed first before any other NAT policy. NAT rules are processed top to bottom. See Also Understanding PAN-OS NAT owner: panagent
View full article
nrice ‎01-22-2010 05:01 PM
42,833 Views
6 Replies
Ask Questions Get Answers Join the Live Community