- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-29-2022 09:37 AM
Hello,
I just turned on logging on my intra and inter zone security rules and noticed that in the security logs a few external ip addresses from zone untrust to zone untrust, with the source of a public ip being allowed, session end reason time out.
How can something be allowed from zone untrust to untrust, that doesnt make sense to me?
the same public ip is also logging from zone untrust to zone trust and policy is denied.
03-31-2022 11:29 AM
Hi @roma ,
I just want to add to @PavelK great explanation:
- Palo FW will make route lookup to determine the destination zone, when packet without a session hit the firewall. Which means that firewall will check its routing table for the destination address.
- If the destination address is IP assigned on the FW interface, the route look up will return the zone associated with that interface. So and since the traffic is comming from internet from and to will be the same zone - untrust.
- If the destination address is IP that is used in NAT policy, the route lookup will be aware of this and will return the zone associated with the route used to reach the translated/internal address. In this case the source is comming from internet and destination (after NAT trannslation) is reachable through through the internal zone, you will see from untrust to trust zone.
- If the destination address is neither assigned on the FW, nor it is used for NAT, the route lookup will again return untrust zone - this is because in your routing table there will be the directly connected network to internet (or if you have purchased additional public range from your ISP, that will be routed to you, but if not used in NAT route lookup will use the default route)
Now having in mind how the destination and source zone are determined, you need to look at the default action for intra and inter-zone rules.
03-30-2022 11:22 PM
Thank you for post @roma
this is expected, the security rule: intrazone-default has default action allow while interzone-default has default action deny, so the log you are seeing are corresponding with security rule action.
Kind Regards
Pavel
03-31-2022 11:29 AM
Hi @roma ,
I just want to add to @PavelK great explanation:
- Palo FW will make route lookup to determine the destination zone, when packet without a session hit the firewall. Which means that firewall will check its routing table for the destination address.
- If the destination address is IP assigned on the FW interface, the route look up will return the zone associated with that interface. So and since the traffic is comming from internet from and to will be the same zone - untrust.
- If the destination address is IP that is used in NAT policy, the route lookup will be aware of this and will return the zone associated with the route used to reach the translated/internal address. In this case the source is comming from internet and destination (after NAT trannslation) is reachable through through the internal zone, you will see from untrust to trust zone.
- If the destination address is neither assigned on the FW, nor it is used for NAT, the route lookup will again return untrust zone - this is because in your routing table there will be the directly connected network to internet (or if you have purchased additional public range from your ISP, that will be routed to you, but if not used in NAT route lookup will use the default route)
Now having in mind how the destination and source zone are determined, you need to look at the default action for intra and inter-zone rules.
03-31-2022 12:05 PM
Thank you Astardzhiev, very nice.
01-01-2024 04:10 AM
Facing a similar issue here: https://live.paloaltonetworks.com/t5/next-generation-firewall/packets-retransmission-captured-in-pac...
Any recommendations?
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!