Hi @arunprakash,
Let me first try to explain how Palo Alto firewall works (skipping some details):
When traffic is passing over PAN FW it will inspect the content of the packets and will try to identify the actual application/service/protocol that is generating this traffic. Palo Alto is developing signatures to be used by the firewall when identifing the traffic. You can browse the database of available signature on the following link - https://applipedia.paloaltonetworks.com/
Palo Alto is using the term "application" for any traffic that can recognize, it could be actuall application, like skype, ms-teams, or protocol like ssh, ping etc.
This way firewall admin can allow only the traffic that is required, not blindly open a port - which could be used by any application and protocol (example, firewall open port tcp/80, but actually and SSH traffic is passed over this port).
When preparing these signature Palo Alto teams define the standard port for application. This server two purposes - it simply firewall administration (admin doesn't need to wonder which ports needs to open if he know what application/protocol is required) and in addition it is used as additional filtering condition when firewall receive a packet and is evaluating/searching for rule match (for example you want to allow SSH, but not when non-standard port like 8080 is used)
As mentioned earlier PAN FW is looking at the data portion of the network packets in order to identify what application has triggered this traffic. But the purpose of SSL/TLS is to encrypt the data so it cannot be read during transmit. Which makes the firewall blind and not capable of identifing the application. Because firewall still withness the TLS negotiation is know that traffic is encrypted so the final verdict for detected application will be "ssl"
"ssl" application is something like "catch-all" that firewall use when traffic is encrypted with TLS or SSL (don't be misleaded by the name, ssl also refer to TLS). As you can see from the screenshot above definition says that standard port for TLS/SSL encrypted traffic is only over port tcp/443 - probably to cover the majority of encrypted traffic which is HTTPS.
What is happening in your specific case is:
1. Client is trying to establish TCP session to destination port 5671/5672
2. The TCP SYN is reaching the firewall, which cannot identify the actuall application based only on this information and based on the exiting rules will allow and forward this packet
3. Client and Server have completed the 3-way-handshake and established TCP session
4. They have start TLS/SSL negotiation
5. Firewall (which inspect any packet from this session) have noticed the encryption negotiation and is identifing the application as "ssl"
6. Because now firewall have identified the application it is performing another policy lookup (search for matching rules), but know it knows it is "ssl" with destination port tcp/5671.
7. Most probably the rule that previously have allowed the traffic was allowing "any application with default ports", and now it doesn't match any more (because it is using application that is using different ports from what is defined as standard), firewall is closing the session
8. For that reason you can see the port as open, but when negitation is started, firewall drops the sessison and client/server application are reporting error as they are not able to complete the TLS/SSL negotiation
For why this is working with one customer enviroment with Palo FW and not with another - there could be couple of reasion and we cannot tell for sure without checking their firewall configuration. There are couple of options how to make this to work with the second customer:
- Create Security Policy rule allowing "ssl" as application and "tcp/5671 and tcp/5672" as service ports - this will allow the negotiation to complete and to forward encrypted traffic over the ports used by the application
- Create Security Policy rule allow "ssl" and "amqp" as application and "application-default" as service ports, in addition create decryption rule that will decrypt the traffic and allow the firewall to "see" belond ssl negotiation and look inside the encrypted traffic and properly identify the used protocol.
- Create Security Policy rule allow "amqp" as application and "application-default" as service ports, in addition create Application Override rule to force the firewall to skip application identification process and always identify traffic as amqp for given source and/or destionation over ports tcp/5671 and 5672
Hi @arunprakash,
Let me first try to explain how Palo Alto firewall works (skipping some details):
When traffic is passing over PAN FW it will inspect the content of the packets and will try to identify the actual application/service/protocol that is generating this traffic. Palo Alto is developing signatures to be used by the firewall when identifing the traffic. You can browse the database of available signature on the following link - https://applipedia.paloaltonetworks.com/
Palo Alto is using the term "application" for any traffic that can recognize, it could be actuall application, like skype, ms-teams, or protocol like ssh, ping etc.
This way firewall admin can allow only the traffic that is required, not blindly open a port - which could be used by any application and protocol (example, firewall open port tcp/80, but actually and SSH traffic is passed over this port).
When preparing these signature Palo Alto teams define the standard port for application. This server two purposes - it simply firewall administration (admin doesn't need to wonder which ports needs to open if he know what application/protocol is required) and in addition it is used as additional filtering condition when firewall receive a packet and is evaluating/searching for rule match (for example you want to allow SSH, but not when non-standard port like 8080 is used)
As mentioned earlier PAN FW is looking at the data portion of the network packets in order to identify what application has triggered this traffic. But the purpose of SSL/TLS is to encrypt the data so it cannot be read during transmit. Which makes the firewall blind and not capable of identifing the application. Because firewall still withness the TLS negotiation is know that traffic is encrypted so the final verdict for detected application will be "ssl"
"ssl" application is something like "catch-all" that firewall use when traffic is encrypted with TLS or SSL (don't be misleaded by the name, ssl also refer to TLS). As you can see from the screenshot above definition says that standard port for TLS/SSL encrypted traffic is only over port tcp/443 - probably to cover the majority of encrypted traffic which is HTTPS.
What is happening in your specific case is:
1. Client is trying to establish TCP session to destination port 5671/5672
2. The TCP SYN is reaching the firewall, which cannot identify the actuall application based only on this information and based on the exiting rules will allow and forward this packet
3. Client and Server have completed the 3-way-handshake and established TCP session
4. They have start TLS/SSL negotiation
5. Firewall (which inspect any packet from this session) have noticed the encryption negotiation and is identifing the application as "ssl"
6. Because now firewall have identified the application it is performing another policy lookup (search for matching rules), but know it knows it is "ssl" with destination port tcp/5671.
7. Most probably the rule that previously have allowed the traffic was allowing "any application with default ports", and now it doesn't match any more (because it is using application that is using different ports from what is defined as standard), firewall is closing the session
8. For that reason you can see the port as open, but when negitation is started, firewall drops the sessison and client/server application are reporting error as they are not able to complete the TLS/SSL negotiation
For why this is working with one customer enviroment with Palo FW and not with another - there could be couple of reasion and we cannot tell for sure without checking their firewall configuration. There are couple of options how to make this to work with the second customer:
- Create Security Policy rule allowing "ssl" as application and "tcp/5671 and tcp/5672" as service ports - this will allow the negotiation to complete and to forward encrypted traffic over the ports used by the application
- Create Security Policy rule allow "ssl" and "amqp" as application and "application-default" as service ports, in addition create decryption rule that will decrypt the traffic and allow the firewall to "see" belond ssl negotiation and look inside the encrypted traffic and properly identify the used protocol.
- Create Security Policy rule allow "amqp" as application and "application-default" as service ports, in addition create Application Override rule to force the firewall to skip application identification process and always identify traffic as amqp for given source and/or destionation over ports tcp/5671 and 5672
