About gwesson

@Frederico said: > Here we are facing a problem with a process in 100% (pan_task process), someone with the same issue? > > Only in PA-200 - pan_task process 100% after 729 update   The pan_task process should always be at or close to 100%, even when there's no traffic passing. You only see it on the 200 in the "show system resources" output because there is not a separate dataplane like on other platforms. You can view the same data on other systems by looking in the dp-monitor.log file if you wanted to confirm.   Depending on the platform, it's one of: less dp-log dp-monitor.log less dp0-log dp-monitor.log less s2dp0-log dp-monitor.log   ... View more

This isn't going to be all that helpful, but you'll probably want to contact Zoho Assist to check. Only they would know if their software can accept an internal CA, even if we could maintain a list of apps that work it would be an administrative nightmare to keep it up to date with vendors who can change their app at any time.   As long as the app either uses the computer's CA store or allows you to import a CA to trust, it should be fine. If the app uses client auth via a certificate, that is not supported and would need to be bypassed. ... View more

@Remo Yep, still needed. A lot of vendors (GoDaddy, Symmantec, etc.) will send you an already-combined chain cert, but sometimes they put the wrong certs in those or they're in the wrong order.   The firewall can show you the relationship, but unless you follow the procedure linked then that relationship is only in the UI and doesn't affect how the firewall sends the cert when making a connection. ... View more

> when I limit my packet capture to those 52.x.x.x addresses I don't see anything except TCP.   In Wireshark, right-click on any of the frames you put in the capture > "Decode As" and choose SSL (change the port to the one you're using, 5671. Don't bother with the source port.):   This will let Wireshark display the actual Client Hello and certificate and such. By default, it only recognizes port 443 and a few others as SSL/TLS, so you have to tell it what dissector to use when it's not that set of ports.   Once you've got that in, you should be able to see where the failure is. Most of the time I see handshake failures caused by something simple like cipher suites not matching. It could be that there's something else, but the capture should help once it's decoded.   As for your original question regarding SSLv3, that's just the name in the code. Something like "pan_ssl3_process_handshake_message()" is just a function name, which can process SSLv3 and TLS alike.   If you can post another screenshot of the packet capture after decoding, it may help.   -Greg Wesson  ... View more

FIPS certification requires that self-tests complete before the interfaces can be used.   The FIPS-Gated flag on an interface that ensures that, while in FIPS-CC mode, the interface does not come up before FIPS mode self-tests have completed. You may see some systems with fips-disabled, which similarly means that in that mode the interface will not be available at all.   If you're not in FIPS mode, the flag isn't used for anything. It's not something that can be modified, so that is likely why there is not much documentation on it. The output of the system state has a lot of things that probably aren't all that useful but are there for debug purposes.   ... View more

There is only one NAT rule that is applied for each session, so the separate Source NAT rule you provided won't get applied when the other one is.   Assuming L3 setup: Run a traceroute from the internal server to the external client IP. Make sure that the MAC address of the firewall your server hits is the same one that is sourcing the traffic inbound from that external client. If not, you've got a routing issue.    If you're familiar with packet captures, you can take one on the firewall (grab transmit and receive stages) at the same time as one running on the internal server. You should be able to confirm if the SYN is making it to the server, if the server is responding with the expected SYN+ACK, and if that's making it back to the firewall.   -Greg ... View more

Most likely, 192.168.0.222 doesn't have a route back to 123.123.2.2, or else it's using a different egress point.   A couple things you can do: 1. Make sure that 192.168.0.222 has a route to 123.123.2.2 and that it goes through the Palo Alto Networks firewall. 2. Use source NAT in addition, specifying the internal IP of the firewall.    Your traffic log detail shows it just barely, 0 bytes and packets received with 62 bytes sent, probably the TCP SYN packet.   Best regards, Greg Wesson ... View more

Any certificate you marked as an "SSL Exclude Certificate" will get converted automatically as part of the upgrade.   If you're just using a URL to exclude from decryption, that is maintained as part of your decryption policy, so the upgrade will keep that as well. ... View more