- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
10-02-2022 08:40 AM - edited 10-02-2022 08:41 AM
Before I post this query, let me declare that I am a newbie to firewalls and their configurations.
I have an application that communicates with Azure Service Bus over port tcp/AMQP 5671/5672. I am facing an issue w.r.t the firewall rules. I requested the outbound ports 5671,5672 be opened for the Service bus hostname in the firewall. I deployed this application to one customer and it is working fine. For another customer where the firewall shows 5671/2 is open, the application registers connection error logs. The firewall team says the application is sending SSL packets over 5671 which is a non-standard way of doing things. I am unable to understand why the same application is behaving differently in two places. The firewall team says TCP/5671 is open but there cannot be SSL headers or packets over it. The firewall is Layer7 PaloAlto for both customers. I tried to show the Microsoft documentation that it is AMQP over TLS and they still say SSL packets over 5671 are disallowed. Please throw some light. Microsoft says this is per AMQP specifications but the firewall team that uses PaloAlto says this is non-standard way of doing things and blocks it calling "SSL over 5671 is non-standard"
10-10-2022 05:22 AM
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
10-10-2022 05:22 AM
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
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!