I have turned on SSL Decryption for my organization and am now receiving reports that iPhone/iPad applications have stopped working and there is nothing in the logs. To test whether the PAN firewall was the cause I contacted a user and put in a policy just for that mobile device source address as a no-decrypt exception. Everything worked.
Q - Is it possible to create a no-decrypt rule based on device? I need to decrypt workstations however mobile devices are less of an issue. Ideally I would like to understand how to work around the apple application programming that is creating the problem and decrypt the mobile device traffic as well but I can't see how that is possible.
What you can do is have decryption profile associated with the decrypt rule and have the option " deny traffic when unable to decrypt " unchecked in there.
That will make sure that the sessions are allowed even if the Palo Alto is unable to decrypt the sessions ( we deny such sessions by default).
Generically speaking, apple devices usually pick TLS version 1.2 which is not supported for decrypting on the Palo Alto.
After exploring the decryption profile settings I logged a case with PAN to ask for clarification on how best to proceed. At this point my ticket is in a researching status with the current answer from PAN being I cannot set a profile to only pass through traffic that the device is incapable of decrypting. Are you aware of how to implement a profile that does not decrypt incompatible traffic however does decrypt compatible traffic? If so, please explain and I will share it with PAN support.
By default the firewall will allow traffic that it cannot decrypt or if the ssl version that is being picked by the client is unsupported.( the traffic will go through and get identified as ssl)
Although while doing Forward proxy the PAN will try and re elect the ssl/TLS version but there is no way to do that for inbound decryption.
Anyway, the point is that unless we enable the option ' Block sessions with unsupported version' in the decryption profile associated with the rule, the firewall will continue to decrypt the traffic that it can decrypt and allow traffic that it is not capable of decrypting.
I guess the best way to proceed with the ticket that you haven open is get the TAC to verify whether or not the version that is being elected in the ssl handshake is supported by the PA to decrypt, if it something that the firewall can handle and still the traffic is getting decrypted, then we have a different issue in hand.
Please let me know if that is not clear.
I suspect the application stop because the certificate which the PAN is presenting is unknown and the application has 1. stopped or 2. awaiting you to ok the unknown cert. This would be success because the decryption worked (pan cert forwarded)
PAN doesn't know the difference between the phones and workstations unless you can enable userID and get the workstations as "known" users or get the mobiles "known" with captive portal. At that time you can exclude or include based on known/unknown user. You also could create a separate wifi network for these mobile devices to connect with. At that point you could ignore them by subnet.
Also another option depending on how many users I believe you may be able to install a trusted root cert on the device directly.
I hope this helps,
Another way is to create a custom application for this kind of device based on the user-agent header.
that allow you to create decryption policy with no decrypt action, based on this custom app.
you could be inspired by this methode explain here : https://live.paloaltonetworks.com/docs/DOC-1247
I like the user-agent header idea - thx. I'll look into that and let you know how it works out. The supplied link goes a long way to explain how to set it up so it shouldn't be long.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!