About gwesson

@SShnap wrote: > I think they should release an application list update, which add working port 443 for web-browsing application. > > I also notice that once you decrypt traffic on 443-SSL it becomes 443-web-browsing, so policy rule that allow web-browsing on application-default will not work, because the application-default is 80. > > You need to create another policy to allow web-browsing application on 443 port.   I had to hold my tongue (well, fingers) because 9.0 hadn't been released yet, but now that it is available I can share this: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-new-features/app-id-features/app-default-strict.html   Now, in PAN-OS 9.0, if an application has a known secure port like web-browsing, your app-based allow rule will work with application-default when decrypting. Currently the app list is web-browsing, SMTP, FTP, LDAP, POP3, and IMAP. Palo Alto Networks can update that list as well via a content update.  ... View more

@Abdul_Razaq they're related, but do different things in their own context. The PBF option is when you could have asymmetric routes, whereas in ECMP it overrides the inherent load balancing that ECMP provides. Both of the following are pulled from the inline help on the firewall from their respective sections:   Symmetric return in ECMP Select Symmetric Return to cause return packets to egress out the same interface on which the associated ingress packets arrived. That is, the firewall will use the ingress interface on which to send return packets, rather than use the ECMP interface, so the Symmetric Return setting overrides load balancing. This behavior occurs only for traffic flows from the server to the client.   Symmetric return in PBF Select Enforce Symmetric Return and enter one or more IP addresses in the Next Hop Address List. Enabling symmetric return ensures that return traffic (such as from the Trust zone on the LAN to the Internet) is forwarded out through the same interface through which traffic ingresses from the internet. ... View more

  It's still being blocked because you're only allowing 'web-browsing' and 'ssl'. Facebook has a large number of unique app-id definitions depending on what you're doing. From Applipedia:     Start with a rule allowing all apps for yourself, then use the traffic log to see the list of apps seen by the firewall when you hit that rule. Then, you can create a more complete rule to allow only what you want. ... View more

It is most likely the site itself. A way to confirm it would be to set up your own server and mirror the list from the original source. Point the firewall at your own server for the EDL source instead. An extra benefit is that you could confirm if the site is ever delivering an error to your server as well by looking at your logs.   I've seen a 503 before (service unavailable) which can commonly happen if the site is overloaded temporarily. If the site is also using a provider like Cloudflare, sometimes those sites can deliver a Captcha page if it sees bot-like activity. ... View more

> Can anyone confirm where Palo Alto tests it's releases against the latest Microsoft OS releases? Yes, it is tested. There are always things that can still break, but that's pretty rare.   > Is there anywhere which details for each Global protect client version, which versions of Windows 10 it has been tested against?  No, just the main version. It's really the same thing with all operating systems. We support Android 9 for example, but don't provide all the various patch versions.   > Does anyone know if Palo Alto work with Microsoft in codevelopment to ensure that Global Protect client keeps pace with the Microsoft OS releases? The regular releases are definitely tested, but there is always a limit of what a 3rd party like PAN (and other vendors) are able to do. If Microsoft makes a big change that isn't available to test before hand, there's no way to plan for something like that. I haven't personally seen that happen before, if that's any comfort.   For HIP data, Palo Alto Networks utilizes Opswat technology for the various components (AV, encryption, firewall version, etc.), and you can see some of the support matrix info here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClkvCAC ... View more

> If you are going to do that, why not at least put out a warning or message.   Not trying to be a jerk here - no warnings or messages are needed if you're running on a supported distro.   The supported versions are few because it is known to work on those versions. It may work on others, but it's just not feasible to make sure every flavor is working or provide guidance when it doesn't.   Not everyone will remember to tell tech support that they're running a Linux distro that's not supported. I've spent more time than I can calculate trying to troubleshoot things like this, and it is really not fun.   Stick with a supported distro. If you want to force it to run on openSUSE Leap, or a Rasberry Pi, or your own custom kernel you can - but I wouldn't recommend it. ... View more

The chain warning just means that the server (firewall in this case) isn't sending the intermediate CAs. It's not usually a problem and will not cause the issue you're seeing, but also has a way to totally eliminate it. Here's an article I wrote that goes into the details: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClkoCAC   As for the handshake_failure warnings seen, those are the real problem. That the Qualys scan shows it failing Chrome 69 and 70 echoes what you see.    I can tell you that the firewall is the one causing this, but whether it's configuration or something else would probably need to be investigated further using the firewall logs and some debugs. I won't suggest that here, it's too dangerous to do unless you're very familiar with the debugging process for proxy-based decryption.    I would recommend opening a support ticket, and would suggest pointing the engineer who gets your ticket to this thread as well. ... View more

> I'm not seeing any communication between it and the firewall.   If you've got decryption enabled between your desktop and the server, then those packets should be the firewall. The IP will still be the client's public IP unless you're doing source NAT for that traffic to the server. I filled in what the bits I think are most relevant to the flow:       SYN --> <-- SYN,ACK     ACK -->     Client Hello -->  <-- ACK <-- Server Hello (+cert, etc.)     RST/ACK -->   Most likely that is actually from the firewall, and the RST you're seeing is because the firewall is denying the traffic based on Server Hello. The most common reasons I see when it happens at the Server Hello are a URL category block or an aggressive narrowly-defined application policy.    You can also check your session on the firewall to see the state when that RST happens. Assuming the client IP is 192.0.2.1, trigger the reset then in CLI: > show session all filter source 192.0.2.1   Once you see the session that matches your client it should be in DISCARD state. Then, take the session ID and do: > show session id 12345678   That should show you more details for the reason. ... View more

Thanks for providing the screenshots!   With that data, it looks like it should work without issue.   Decryption was enabled when you did the Qualys scan right?If no, you'll need to re-enable it and re-run it to ensure it still matches. If decryption was enabled when you ran it, my next recommendation would actually be to open a support case unless you're comfortable posting the details here. ... View more

You will need to remove the "application-default" on that rule, because once the SSL is stripped and the underlying application is seen, it's still on port 443 which is not in the list of default ports on 'web-browsing'.   The logic may seem odd, but it follows this flow: 1. Traffic is identified as SSL when the Client Hello is seen. 2. Decryption starts here, and when the TLS handshake is completed the app-id switches from "SSL" to "Web-browsing". 3. Because the app has changed, it is re-evaluated in security policy. Since the app is web-browsing, but it's not on port 80 as defined in the app, rule 4 will be skipped. 4. The application has no matching rules, so it falls to the Interzone-default which denies the rest of that session. ... View more

The Firefox error is better in terms of what it's saying: no cipher overlap.   When your client sends the Client Hello, it will specify some number of cipher suites that it supports. When the server (your firewall in this case) gets that list, it tries to match with the highest security cipher in that list. But if the firewall doesn't have any that match the client's list, you will get the error that you got.   Check a few things: 1. Your decryption profile on the firewall should include at least one cipher that the client is sending. Go to Objects > Decryption > Decryption Profile and hit the SSL Protocol Settings on the profile you use in your decrypt rule for this traffic. 2. While you're there, make sure that the "Protocol Versions" is set with the max version of "Max". Chrome has recently stopped supporting TLS 1.0, and others (Firefox, Edge, Opera, Safari, etc.) may have as well or will be soon), so if you're maxing that out at TLS 1.0 or 1.1, you'll be out of luck for most browsers. 3. Make sure that your browsers are configured to send all the DHE and ECDHE ciphers it should, and that they haven't been artificially limited by some setting on your end. 4. Run a TLS check (Qualys has a popular one for free) to see what you're supporting if the site is publicly accessible. ... View more

Google pushed the full enforcement to Chrome version 73 (unless they push it again). They have enabled it in version 72 but only if you don't trust the CA.   The advisory has now been updated to reflect this new info: https://live.paloaltonetworks.com/t5/Customer-Advisories/Action-required-if-you-have-enabled-SSL-decryption-forward-proxy/ta-p/236596   ... View more