About gwesson

To make it work, just take the CA certificate that your forcepoint system is using to create the certs for users.    Device tab > Certificate Management > Certificates > Import. Select the forcepoint CA's public key. Once that's done, click the cert name in the UI and click the "Trusted Root CA" checkbox. Hit ok, then commit.    The firewall should trust any future connections from that cert. ... View more

You should only get a prompt if the client has multiple certificates signed by the same CA on the firewall's GP cert profile config.   If you have any other client certificates from the same CA as the one for GP, the prompt will happen each time. If you don't need those other certs for any reason, you can delete them to avoid the prompt. ... View more

It only updates when connecting to the portal itself, not while connected. With the transparent option enabled, the user will not see anything other than GP reconnecting after the upgrade is completed.   With the setting enabled and the GP client on an older version than the bundle on the firewall, launch GP and confirm the version then connect (successfully) to the firewall. Once the upgrade is complete and GP has reconnected, you should see the version updated. ... View more

The expression you've listed doesn't work the way you're intending.   ([518497|518472|518536]{6})([0-9]{10})   The way a regex works when it comes to square brackets is a list, not a string. Every digit 1-9 is included in the three values you provided (highlighted in red below):  [518497|518472|518536]   So the regex as it's written above is essentially the same as: [1-9]{6}[0-9]{10}   Which is to say that it matches any of the following: 1112221234567890 9999999999999999 5371627591995601   The regex to match what you want may be: 518497|518472|518536[0-9]{16}     That won't work on the firewall though, it needs 7 non-token characters to start the match, and the values you provided are only six characters. Additionally, you added "503441" to your first reply to @Brandon_Wertz so there may be more you're trying to match against.   If you can put some of the actual strings you want to match it may help.  ... View more

Are you applying NAT to that traffic?   If the source 192.168.123.123 is not getting the public NAT address of your interface, you won't be able to get a reply. You can test if it's got a NAT match with the CLI test command:   > test nat-policy-match protocol 6 source 192.168.123.123 destination 8.8.8.8 destination-port 443 ... View more

A handshake failure is unfortunately very generic and doesn't explain *why* there was an error, just that there *was* an error. It's the nature of the encryption so there's not much you can typically learn from just that.   You'll likely want to open a support ticket, as there may be more troubleshooting steps that can fork depending on some results. Generally, the times I see a handshake failure are:   - An unsupported cipher - A blocked cipher (via the Decryption Profile) - The server requires client certificate authentication   But beyond those three, you'll probably want some official support in troubleshooting it. ... View more

> Even with Decryption enabled PANOS still doesn't match the Parameters in the URL.   That's actually incorrect - PAN-DB (and PAN-OS) does do full URI matching. The two test URLs I provided would illustrate that. The "test-phishing" and "test-gambling" parts are neither the host nor the domain. Those are part of the path, and PAN-DB definitely does page-level categorization, even when you define a custom URL.   Looking at the squid rules you provided, you would likely need to create a custom URL category with all of the following URLs. :   www.google.com/favicon.ico www.google.com/images/branding/product/ico www.google.com/maps* www.google.com/xjs* www.google.com/s?tpm=map www.google.com/search?tpm=map www.google.com/gen_204/?oq=*   You may want to double up on those, excluding the 'www' since it's valid even without that. ... View more

Are you doing SSL Decryption? Without decryption, the firewall doesn't even see the HTTP request for the maps page, it only sees the hostname of the server they're connecting to, in this case it's www.google.com as the host. Google uses a wildcard cert, so the response from the server is for *.google.com. Since neither is distinguishing the maps service, there would be no way to allow maps but deny others.   PAN-DB does categorize on full URIs, not just domains and hosts. A good example of this is any of the test sites: https://pandb.paloaltonetworks.com/test-gambling https://pandb.paloaltonetworks.com/test-phishing   Both of those pages are on the same host and domain, but different paths. PAN-DB will categorize them appropriately.   But if you're not decrypting the SSL (TLS) traffic, the only thing the firewall will see is a TLS Client Hello that has "pandb.paloaltonetworks.com" but not the full URI. ... View more

> If PA is working as proxy, we should not get any unsupported parameter error as PA will be involved in selecting ciphersuit.    Not quite right. The firewall supports a specific subset of ciphers, and if your client is only presenting non-matching ciphers you'll fail to establish the connection. The full list is here, with the ECDHE and DHE on the bottom: https://docs.paloaltonetworks.com/compatibility-matrix/supported-cipher-suites/cipher-suites-supported-in-pan-os-8-0/cipher-suites-supported-in-pan-os-8-0-decryption.html   You don't need to manually enable proxying, it's always a proxy. Starting in 8.0, both inbound and outbound is acting as a proxy.   I didn't see any specific error message in your original post, so I don't know what "parameter error" you're referring to, but the ciphers is typically the easiest to confirm.    If your site is public, you can use Qualys SSL scaner or even nmap to see what ciphers are supported. ... View more

All UDP sessions will show their session end reason as "Aged Out" if the traffic is allowed through the firewall. UDP doesn't have a concept of an explicit close, so if it's not dropped because of a threat or policy deny, "aged out" is the only possible end reason. That much is common, you won't have to worry about that.   As for the application showing "Insufficient-data", that just means that not enough packets have been seen by the firewall to accurately identify the app itself.   Take a look at the session output from the CLI (show session id 12345678). You should see the client-to-server (c2s) and reverse (s2c) flows which will show your IPs as well. Check to ensure that the correct NAT addresses (if needed) and make sure that the firewall's routing table (show routing route) is correct to be able to route the traffic in both directions.   If you'd like, paste the result of one of those aged out sessions here. Also, hit the "insert code" icon, you can paste the results in a cleaner format for viewing on these forums, like below.   Here's an example I took from my own firewall that has the same details (IPs changed for privacy). You can see that only 1 packet in each direction was seen, which wasn't enough to identify the application. The end reason is also aged-out, because it's UDP (protocol 17): > show session id 13736 Session 13736 c2s flow: source: 192.168.1.1 [Trust] dst: 1.2.3.4 proto: 17 sport: 32047 dport: 8814 state: INIT type: FLOW src user: unknown dst user: unknown qos node: ethernet1/1, qos member N/A Qid 0 s2c flow: source: 1.2.3.4 [Internet] dst: 123.222.111.333 proto: 17 sport: 8814 dport: 29065 state: INIT type: FLOW src user: unknown dst user: unknown start time : Tue Jan 15 13:22:33 2019 timeout : 30 sec total byte count(c2s) : 201 total byte count(s2c) : 219 layer7 packet count(c2s) : 1 layer7 packet count(s2c) : 1 vsys : vsys1 application : insufficient-data (insufficient) rule : Exclude Logging service timeout override(index) : False session to be logged at end : False session in session ager : False session updated by HA peer : False address/port translation : source nat-rule : Default Outbound NAT(vsys1) layer7 processing : enabled URL filtering enabled : True URL category : any 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/1 session QoS rule : N/A (class 4) end-reason : aged-out ... View more

PAN-OS 8.1 introduced rule hit counters, so that's probably the easiest way to do what you want. If you're stuck running 8.0 for now, the best you have is the "Highlight Unused Rules" checkbox at the bottom of the rule base that will highlight any rules not hit since the firewall was last restarted.   ... View more

Starting with PAN-OS 8.0, it supports inbound with DHE/ECDHE. See this in the new features guide: 8.0 Inbound PFS It is proxying the TLS traffic. That is the only way to decrypt DHE/ECDHE, since (by design of the exchange mechanism) it cannot be decrypted passively even with the private key. ... View more