This Nominated Discussion Article is based on the post " What would this number be at the end of some signatures? " by @filipe.r.oliveira and answered by myself, JayGolf!
Guys, I saw that there is a different number sometimes in the same signature. What would that be? what is it for? Is there any documentation talking about it? If I block the subscription with a number and another one appears with another number, do I have to do this blocking too or do these numbers not interfere with the subscription blocking and just put the name? example:
1- DESCRIPTION AndroxGh0st Scanning Traffic Detection(86759) 2- DESCRIPTION AndroxGh0st Scanning Traffic Detection(86760) If you can help me with these questions, please!
Thank you for your attention!
These numbers represent the version number of the signature. In this case, "DESCRIPTION AndroxGh0st Scanning Traffic Detection(86760)" is the later version of the signature. You don't need to manually block each version as the latest threat updates include the most recent signatures.
In today's digital world, where encryption is all around us, SSL decryption becomes a real superhero in the fight against hidden threats and bolstering network security. Luckily, Palo Alto Networks Next-Generation Firewall comes to the rescue with its powerful SSL decryption capabilities.
This Nominated Discussion Article is based on the post " Palo Alto BGP routes from Azure " by @S_Williams901 . Read on to see Cyber Elite @aleksandar.astardzhiev response!
Palo 5220 running at the edge, using VPN tunnel to Azure virtual WAN running eBGP. Palo iBGP peered to switches, switches peered eBGP to Azure Express Route. My issue is VPN route is always installed in route table rather than express route, I assume because eBGP is AD 20 vs iBGP AD 200. I have tried local pref and weight on the palo to try and force it to install iBGP route coming from Express route with no luck. Any one else have a similar issue?
During route lookup administrative distance is always first to check, so no matter what MED, local pref or weight you set eBGP will always be preferable. AD is used to select route learned from different routing protocols, while the BGP metrics will be used when multiple routes from same routing protocol were learned.
Obviously the quick and dirty fix is to increase (or decrease) administrative distance metric for either iBGP or eBGP. However you need to double check how this will effect any other routing in your environment, since this change is per virtual-router and will affect all routes
Have you considered the option to use eBGP between firewall and switches? You could assign dedicate private AS number to the firewall, which is different from the AS of the switches. This way you could play with BGP metrics and tell FW to use express route when available.
Experiencing an issue where Commit to the panorama succeeds, but push to the device fails with status 'none' and error message as ' no detail'? Read to see @Tom-Lee's findings. Thanks for sharing with the community!
We recently had this issue where after upgrading firewalls to 10.1 the panorama gave an error on push to certain firewalls with the description "none" which wasn't very helpful. On further process eliminating we discovered it was only VM FWs in AWS the error occurred on. Panorama wouldn't even try to push the device templates or give any meaningful error messages.
It was only when prompted we checked the plugin versions. Panorama 10.1.8-h2 after the upgrade had vm_series-2.1.6 where as the firewall image include vm_series-2.1.7!
A reminder to all on PAN-OS updates not just to check your Panorama is a higher or equal version of Software but also the AV/Threat/ AND plug-in versions!
The reason template push failed specifically to AWS is that we utilize Cloudwatch configuration in the template for AWS where as other VM series didn't have this configuration in the template. The error was not shown in Panorama but basically the template was not compatible with the firewall as Panorama did not have support for 2.1.7.
Other strange issues on upgrade from 9.1.x to 10.1.x :-
We also had issues when setting User ID redistribution agents and they would not connect to panorama or some firewalls. When using default secure comms certificate the built-in PAN-OS certificate is used, and if this expires again no messages are displayed to make this obvious but in our case the scheduled dynamic content update after upgrade hadn't worked and it required a manual check now, download and install of the latest content version to refresh the built in certificate. This is not to be confused with other FW certificates as there is also device certificate (used to communicate with Palo Alto Cloud), Cortex Data Lake specific certificate (used to communicate with customer specific instance) in addition to the user based certs that can be installed for Management console or SSL decrypt / Client auth.
Creating this article to help others searching for quick answers!
See also here https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wkupCAA
This Nominated Discussion Article is based on the post "Aggregate interface per cli " by @Shadow and answered by @Metgatz . Read on to see the discussion and solution!
I am in search of how to create an aggregate interface per cli.
I am using eve-ng and the option to create the ae via the GUI is not available.
set network interface aggregate-ethernet ae1 layer2 lacp enable yes
set network interface ethernet ethernet1/3 aggregate-group ae1
set network interface ethernet ethernet1/4 aggregate-group ae1
set network interface aggregate-ethernet ae1 layer2 units ae1.100 tag 100
set address 192.168.1.1 ip-netmask 192.168.1.1/24set network profiles interface-management-profile Trust https yes
set network profiles interface-management-profile Trust ssh yes
set network profiles interface-management-profile Trust snmp yes
set network profiles interface-management-profile Trust ping yes
set network interface vlan units vlan.100 ip 192.168.1.1
set network interface vlan units vlan.100 interface-management-profile Trustset zone Trust-L3 network layer3 vlan.100
set network virtual-router default interface vlan.100
set network vlan vlan100 virtual-interface interface vlan.100
set network vlan vlan100 interface ae1.100
set import network interface [ ae1 ae1.100 vlan.100 ]commit
This article is based on a discussion, " Precedence of Routing\NAT\Policy ". Read on to see Cyber Elite @TomYoung's response!
Hello, I am following this guide to set up ISP failover.: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLL8CAO
The problem is that my failover ISP (Starlink), does not provide me a static IP address
How would you recommend accomplishing what I want to do when the failover ISP provides a DHCP address?
If you want the static ISP to be primary, and the DHCP ISP to be secondary, configure the static route for the static ISP just like the document. Then set the metric for the DHCP default route to be higher than the static route.
Only the default route to the static ISP will be active (A) in the route table (Show Runtime Stats). When there is a failure (cannot ping the Path Monitoring IP addresses), that default route will be removed. The DHCP ISP default route will then be used.
Very important! Do not use only one destination IP address under Path Monitoring! Use at least 2 with the Failure Condition set to "all." Then if one public IP goes down for maintenance, your Internet does not fail over.
This article is based on a discussion, " Precedence of Routing\NAT\Policy ". Read on to see Cyber Elite @TomYoung's response!
I want to know what is correct precedence among Routing\NAT\Security Policy
So If a packet hits on the outside zone of the Firewall then whether below process is correct?
1. Whether FW has route for the destination\18.104.22.168 ( If YES)
2. Whether there is any NAT policy (If YES) ( Assume -> After NAT, 22.214.171.124 translated to 126.96.36.199)
3. Then security policy should allow original destination IP(188.8.131.52) or Translated destination IP (184.108.40.206)
Great question! A good general rule is "Pre-NAT IP, post-NAT everything else." For example, in this document -> NAT Configuration Examples the IP in the security policy is pre-NAT, while the destination zone is post-NAT. Scroll down to the bottom to see the NAT and security policy rules.
With regard to precedence, a good diagram is this one taken from the PCNSE study guide on Beacon.
Of the order you mentioned, the route lookup is done 1st (Forwarding Lookup). Then the NAT policy lookup is 2nd (DNAT check). However, NAT is not applied to the packets until the egress interface (Forward Traffic). The forwarding/NAT lookup is necessary to determine the destination zone. Then the security policy is checked last. That is why the IP address in the security policy is pre-NAT.
This article is based on a discussion, "IPSEC Tunnel to ASA". Read on to see the solution!
I am setting up an IPSec tunnel to an ASA. I am getting an error message about the PEERID type only allowing IP but receiving FQDN. Per the other KB article, I changed the PAN Exchange mode to Aggressive.
Now the PAN received an FQDN of the ASA side and gave listed the FQDN in the system logs.
My question.. where in the ASA can you configure PEER and LOCAL ID in the Phase1 settings? I am not seeing that option so I cannot figure out how the PAN is getting the FQDN.
Configure PA Firewall (Network > IKE Gateways > Configure IKE Gateway), as in the example below. Ensure that the Local and Peer Identification match with the Cisco Router.
Note: Use Aggressive Exchange Mode and Enable Passive Mode if the other end is a Dynamic IP. Choose a local and peer Identification for IKE phase 1 and match this to the Cisco Router Configuration.
With the Cisco router in VTI mode, configure IKE Gateway (see example below). Again, ensure that the Local and Peer Identification match with the Palo Alto Networks firewall.
With the Cisco router in equivalent Crypto Map mode, configure IKE Gateway (see example below).
This article is based on a discussion, "ECMP ". Read on to see @Raido_Rattameister's response!
Our question is "How can the firewall choose the route without configuring the ECMP?"
Appreciate your support as mentioned in this documentation:
" Without this feature, if there are multiple equal-cost routes to the same destination, the virtual router chooses one of those routes from the routing table and adds it to its forwarding table; it will not use any of the other routes unless there is an outage in the chosen route"
If you have multiple route entries to same destination with same metric you need ECMP to be enabled.
ECMP path choosing methods are:
- IP Modulo (default)—The virtual router load balances sessions using a hash of the source and destination IP addresses in the packet header to determine which ECMP route to use. - IP Hash—There are two IP hash methods that determine which ECMP route to use: If you select IP Hash, by default the firewall uses a hash of the source and destination IP addresses. If you Use Source Address Only (available in PAN-OS 8.0.3 and later releases), the firewall ensure that all sessions belonging to the same source IP address always take the same path. If you also Use Source/Destination Ports, the firewall includes the ports in either hash calculation. You can also enter a Hash Seed value (an integer) to further randomize load balancing. - Weighted Round Robin—You can use this algorithm to take in to consideration different link capacities and speeds. When choosing this algorithm, the Interface dialog opens. Add and select an Interface to include in the weighted round robin group. For each interface, enter the Weight for that interface (range is 1 to 255; default is 100). The higher the weight for a specific equal-cost path, the more often that the equal-cost path is selected for a new session. A higher speed link should be given a higher weight than a slower link so that more of the ECMP traffic goes over the faster link. You can then Add another interface and weight. - Balanced Round Robin—Distributes incoming ECMP sessions equally across links.
Other option is to use Policy Based Forwarding.
PBF will be checked first and if traffic matches PBF policy then PBF route takes precedence and virtual router routes are not checked.
You can't configure multiple routes with same metric if you don't enable ECMP.
So without ECMP metric is used to decide route.
Smaller metric configured on static route will take precedence.
The commit will fail if you have multiple routes to same destination with same metric without enabling ECMP.
This article is based on a discussion, Security Profiles - URL Filtering - Update Multiple Categories within all Profiles.
Read on to see how @PingMyServer was able to accomplish this from the CLI.
Hello all, I'm looking for some suggestions, or information on how I can quickly update all security profiles, with 3 select objects at once. In total, our Panorama has 129 profiles, so I would need to login to all 129 profiles, and update 3 categories in them to block.
By way of the gui, I think the only way would be able to edit 1 profile at a time, and search all 3 categories, and update them accordingly. Can anyone suggest any easier way to maybe resolve this?
Solution for Update Multiple Categories Within All Security Profiles With the CLI:
After doing further research, I found through the CLI you can do this fairly easy. Using the following commands. You can pull your profile names from the command "set device-group GROUP1 profiles" and pressing tab. It takes a little work, but with excel you can get all the commands you need fairly quickly
set device-group GROUP1 profiles url-filtering PROFILE_NAME block ransomware set device-group GROUP1 profiles url-filtering PROFILE_NAME block encrypted-dns set device-group GROUP1 profiles url-filtering PROFILE_NAME block real-time-detection
This article is based on a discussion, How to Configure GRE over IPSEC?, posted by @ZhouYu. Read on to see the solution!
Some implementations require multicast traffic to be encapsulated before IPSec encrypts it. If this is a requirement for your environment and the GRE tunnel and IPSec tunnel share the same IP address, add GRE Encapsulation when you set up the IPSec tunnel.
PAN-OS TechDocs: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/networking/gre-tunnels/gre-tunnel-overview.html
How do you configure GRE over IPSEC？
How to configure?
@v.vittih's Accepted Solution:
Hi all! There is a working version of this GRE over IPSec.
According to the official manual from Palo Alto Networks, there are 2 options for creating this bundle. In the first case, when the source and destination addresses are the same (as in my case) and the source and destination addresses are different.
Let's start setting up: Side A: PanOS 10.2 WAN: 10.10.2.50 LAN: 192.168.50.0/24 VTI IP: 10.200.200.1/30
Side B: Mikrotik: RouterOS 7.6 WAN: 10.10.2.60 LAN: 192.168.10.0/24 GRE IP: 10.200.200.2/30
Let's start with PaloAlto: Create a tunnel (for example 1), add it to the default router and register the ip address 10.200.200.1/30 on it. Next, we create IKE Crypto, IPsec Crypto with the settings that you need. Create IKE Gateways (I use IKEv2 only mode), then specify Local IP Address 10.10.2.50/24 and Peer Address 10.10.2.60, specify PSK, specify Local Identification 10.10.2.50 and Peer Identification 10.10.2.60. also do not forget to specify IKE Crypto Profile on the Advanced Options tab:
Next, we proceed to configuring IPsec Tunnels: Select the previously created tunnel 1 Select the previously created IKE Gateway Select Show Advanced Options and select Add GRE Encapsulation Go to the Proxy IDs tab and add the IP addresses of our external interfaces: Local 10.10.2.50 Remote 10.10.2.60
Don't forget to specify routes: Virtual Router -> Static Routes: add -> Destination 192.168.10.0/24 Interface tunnel 1 Next Hop IP Address 10.200.200.2
Moving on to Mikrotik: Interfaces -> GRE Tunnel Creating a GRE tunnel Specify Local Address 10.10.2.60 Specify Remote Address 10.10.2.50 OK Next, add the IP address to the interface: IP -> Addresses add 10.200.200.2/30 ok Moving on to creating IPsec: IP-> IPSec
Creating a Profile We specify the data we need
Creating Identites: Specify the PSK My ID Type Auto Remote ID Type Auto
Creating Peers: Specify Address: 10.10.2.50 (IP Address of party A) Local Address: 10.10.2.60 Specify IKE profile Exchange Mode IKE2
Creating a Proposal: We specify the data we need
Creating Policies: Specifying Peer Select Tunnel Src.Address 10.10.2.60 Dst.Address 10.10.2.50 Protocol 255(all) On the Action tab, do not forget to specify the Proposal. We specify the routes to the network we need (in my case it is 0.0.0.0/0 10.200.200.1 so that there is Internet access in the office via PaloAlto) Within the current example 192.168.50.0/24 10.200.200.1 Profit.
This article is based on a discussion, Source NAT with Pool, posted by @nattapong_thi. Read on to see the guidance from Cyber Elite @Astardzhiev!
For example, we use 220.127.116.11/24 as internet facing interface
What is the difference between
18.104.22.168/24 and 22.214.171.124/32
Which one is correct? When I configure a /24 it seems there's a conflict displayed
When you use Dynamic IP and Port for source nat, you have two options for defining what address to be used for translation:
- Interface address - if you select this one, you tell the firewall to use the IP assigned to that particular interface to be used for translation. In this case firewall will translate all internal sources to single IP - the one configured on selected interface. On other words this is many-to-one translation
- Translated address - if you select this one, firewall is expecting you to configure valid IP pool that it will use for translation. In this case you define how big is the pool. If you use /32 prefix, this means that pool consist of single IP and it is again same as many-to-one translation. If you use /24 prefix this means that pool has 255 available addresses, which firewall can use for translation - this is many-to-many translation.
126.96.36.199/32 is valid configuration, because /32 prefix define range of single IP
188.8.131.52/24 is not valid configuration, because /24 prefix define range of 255 IP addresses, so the .30 is not the beginning of the prefix, but represent a host in that range.
When you are configure your outside interface with 184.108.40.206/24 this is now valid, because you tell that FW is assigned with IP .30 from a /24 network, from which firewall can identify the length of the network, network mask etc.
In your specific case you can use either of the two:
- Use "Interface address" for address type and select the interface of the outside/untrust interface.
- Use "translated address" for type and enter /32 pool
This article is based on a discussion, Dual ISP Global Protect Redundancy , posted by @DonohoeRobert. Thank you for the insight!
I hope ye all are well. We recently worked a case for a customer that had dual ISP configuration and wanted the Palo Alto Networks device to provide redundancy for the Global Protect Portal and Gateways in the event one ISP went down. We came up with a handy way of providing this using NAT rules and a loopback and I am posting this to share with the community.
There are some screenshots from the lab below. Eth1/1 & Eth1/2 represent ISP-A and ISP-B.
We popped the Global Protect Portal and Gateway on a loopback interface.
We created two NAT rules to bounce the incoming traffic whether its from ISP-A or ISP-B to the loopback address.
The system has two Virtual Routers for both ISP's. VR-A and VR-B. VR-A has the loopback interface added.
Virtual Router B has a static route to VR-A which has a route to the loopback interface with the Portal and Gateway.
This simple setup allows access to the portal and gateway from either ISP interfaces. We simulated one ISP failing and changed the A record of the portal fqdn to resolve to the other interface and the users could connect without any input or changes from the end user. There are a number of ways to automate dns integrity and failover to resolve to a different ip address if it can't resolve to another. Beyond the scope of Palo Alto. Infoblox and Route 53 can provide these features. If you just have an MS server, changing the A record from one IP to another isn't a massive task.
Hope this helps few others and is nice way to provide an extra layer of redundancy for networks to big to fail.
This article is based on a discussion, Tracing external IPs back to internal IPs at a specific moment in time..., posted by @Tom_Access . Read on to see the solution and collaboration from Cyber Elite @OtakarKlier & @Adrian_Jensen!
In the course of tracking down security vulnerabilities, I find myself trying to trace External IPs (from external security scan reports) back to Internal IPs at a specific moment in time (the timestamp from the scan report). Most of the time, it's very simple, as many internal IPs are NAT'd 1-to-1 to external IPs. Those tend to stay static. But there are also large groups of PAT'd addresses, such as whole ranges of internal IPs (like guest WiFi network DHCP pools) that go out a single external IP.
I'm really struggling with how to track these devices down. I can rarely even find a matching internal IP for that timestamp.
Is there a specific NAT/PAT log I can reference? Or a tool for this that I'm missing? I've been trying to use the traffic logs, but that's not always fruitful and it is tedious.
Any suggestions? I'm using a Palo Alto PA-5250 running PanOS 10.2.0.
Thanks in advance,
First thing is to make sure you have logging at session end enabled on all of your security policies. Then you go into the Unified log and filter on source IP of the attacker. This should show all the traffic from that IP address. Then click on the paper/magnifying glass icon on the far left of the log.
This will bring up all the session details and will show you the NAT'd IP.
In addition the Monitor -> Logs -> Traffic viewer has many additional fields which can be selected/filtered upon by selecting the down arrow in the column name header and selecting additional fields. (Note: You can also reorder columns by dragging them to either side.)
Two additional columns that are not shown by default are "NAT Source IP" and "NAT Dest IP" (as well as NAT Source/Dest Port), which show the NAT'd IP results. You can filter you traffic on these fields as well. So, for instance, if you external security report complains about an exploit attempt from your public IP to an internet IP:
2022-07-08 12:35 - 220.127.116.11:53219 -> 18.104.22.168:443
You can find all the matching outbound traffic logs with a Traffic log filter like:
( natsrc eq 22.214.171.124 ) and ( natsport eq 53219 ) and ( addr.dst in 126.96.36.199 ) and (port.dst eq 443)
You can further add time filters to narrow down a window, though be aware that while log receive time appears to be a log database index, session start time is not. So queries using start time may take much longer/time out when searching (you can work around this by also using a wide receive time filter to pre-narrow the results subsequently filtered by the start time filter).
... and (receive_time geq '2022/07/08 12:30) and (receive_time leq '2022/07/08 12:50) and (start_time geq '2022/07/08 12:30)
This article is based on a discussion, Multiple ISPs with Path Monitoring, posted by @securehops. Read on to see the solution and guidance from Cyber Elite @aleksandar.astardzhiev!
Need a sanity check. When deploying multiple ISPs using path monitoring, instead of policy-based forwarding, should the second ISP become unreachable? It makes sense that it does, but it wasn't mentioned in a Palo Alto Networks article.
Setup would be:
ISP1 (e1/1) 0.0.0.0/0 188.8.131.52 priority 10 (with path monitoring)
ISP2 (e1/4) 0.0.0.0/0 184.108.40.206 priority 200
VPN tunnels for both ISP1 and ISP2 using tunnel monitor
With this config:
ISP1 tunnel is up, e1/1 is pingable from outside
ISP2 tunnel is down, e1/4 is NOT pingable from outside
If you don't use PBF, this behaviour is expected.
Without PBF, firewall will try to establish VPN with source IP assigned on eth1/4, but it will forward the traffic over eth1/1 and ISP1, where most probably traffic will be dropped, since it is sourced from IP that doesn't belong to this ISP.
In this case, ISP2 tunnel should come up, in case of failover - path monitor fail and remove default over ISP1
and ISP1 tunnel will go down, respectively.
If you prefer to have both tunnels IP and ready, you could create a PBF so traffic sourced from eth1/4 to always go over ISP2.
I personally always try to avoid PBF, primarily because engineers often forget to check it during pacy troubleshooting. However, the truth is PBF could be very helpful in some situations.
I would say:
- If you need simple failover between two ISP absolutely go for path monitor on static route
- But in addition to the failover you need faster recovery for the IPsec tunnel you will need PBF to keep the second tunnel ready to take over.
Don't forget to you either case you will need tunnel-monitor or PBF with path-monitor for the routing over the tunnel. Once primary tunnel goes down, you need to switch the route to second tunnel. You could again create PBF that will monitor the path over the tunnel and when down, to switch to second. This was the preferred way for IPsec failover way-way back. May preferable way is to use tunnel-monitor, so firewall will "disable" the static route pointing to tunnel1 and fallback to route pointing to second tunnel.
Regarding the monitored host...I am not the best person to define best practices. I have had few cases where path-monitor was required and in all cases we used 220.127.116.11 and it was fine.
This article is based on a discussion, Issue that specific policy traffic logs fail to forward to syslog server and drop from firewall, posted by @JoHyeonJae. Read on to see the discussion and guidance from @PavelK!
Hello, PAN-OS : 9.1.6 Currently, my customer is facing Issues where logs generated (TO_DNS policy) from a specific policy of more than 10,000 LPS are dropped without being forwarded to the syslog server.
The Traffic Log of the firewall is verifiable, but the Forwarding Stats Syslog Drop Count is constantly increasing, debug log-receiver statistics have been confirmed, and less than 1,000 Total LPS appear in addition to this policy. There is no logs for that policy on the syslog server because it is dropped without being forwarded by the firewall. The Log Setting/Log Forwarding Profile in the policy settings is set normally, so it seems to be no problem with the settings. I will let you know, if you guys need additional info. The Device Log Forwarding Limit of PA-3260 is written in 24,000/LPS as shown in the document below, so I wonder why it is dropped.
your customer might be hitting an issue PAN-185616 addressed in 9.1.14:
This article is based on a discussion, Best guides for new Firewall Deployment, posted by @nhussain03. Read on to see the discussion and guidance from @OtakarKlier.
I am deploying a new firewall for a PoC; however, I am having some issues. I have deployed and activated the server on Azure, I am using VM-Series. On the Azure side, there being no restrictions, the server is not able to connect to the internet for updates. I must be missing something basic in understanding/setup so any pointers would be great.
If you are looking for a place to start when configuring your new firewall, check out this post to get started: Secure Day-One Configuration Not for the Faint of Heart.
Sounds like a routing/policy issues with the original PAN you deployed. I wouldn't recommend having the management interface internet facing unless you lock it down to source IP's. However you can change the services, so they use a different interface to reaching out and grabbing updates, etc.
If you're adventurous — https://live.paloaltonetworks.com/t5/general-articles/secure-day-one-configuration-not-for-the-faint-of-heart/ta-p/435501 — it blocks almost everything so be careful.