08-09-2020 05:17 PM
Hi,
I am looking to block the RFC 1918 blocks coming from internet to our LAN zone. So, Policy will be Source zone: Public , IP: RFC1918 blocks, Destination zone: LAN, IP : any .
Can you guys please confirm that creating this policy will fulfill my requirement?
@OwenFuller can you please give your input?
Thank you
08-09-2020 08:35 PM
That will work as you expect. Are you actively seeing 1918 addresses coming across your untrust interface on the ISP side of things though? If so, the one thing you will want to double check is that your untrust interface actually has a public IP address being assigned to it, and not an RFC 1918 address which is being NAT'd by the carrier.
08-10-2020 06:49 AM - edited 04-27-2021 11:39 AM
@shafi021 it looks like @BPry got you taken care of with his reply. I would just add that even if your firewall isn't using a public IP, and your ISP was doing a source NAT on your outbound traffic, I wouldn't expect it to be doing any source NAT on the return traffic. You would most likely see that the return traffic has the proper public IPs. Also, the return traffic for established connections (those initiated from your LAN to the Internet) should be allowed anyway.
You would most likely only have an issue w/ RFC1918 traffic going from your Public zone to your LAN zone if you were both 1) using private IPs on your firewall's Public interface because your ISP is doing source NAT, and 2) needing some other device on the network between your firewall and ISP's device (the Public zone according to the firewall, but the private side according to the ISP's NAT device) to the firewall's LAN zone.
If you're interested in a more comprehensive BOGON list than just RFC1918, I'm a fan of CYMRU's Full Bogon list, which also includes public IP ranges not yet allocated by IANA. It can be used as an external dynamic list (EDL) on the Palo Alto firewall.
https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/
08-09-2020 08:35 PM
That will work as you expect. Are you actively seeing 1918 addresses coming across your untrust interface on the ISP side of things though? If so, the one thing you will want to double check is that your untrust interface actually has a public IP address being assigned to it, and not an RFC 1918 address which is being NAT'd by the carrier.
08-10-2020 06:49 AM - edited 04-27-2021 11:39 AM
@shafi021 it looks like @BPry got you taken care of with his reply. I would just add that even if your firewall isn't using a public IP, and your ISP was doing a source NAT on your outbound traffic, I wouldn't expect it to be doing any source NAT on the return traffic. You would most likely see that the return traffic has the proper public IPs. Also, the return traffic for established connections (those initiated from your LAN to the Internet) should be allowed anyway.
You would most likely only have an issue w/ RFC1918 traffic going from your Public zone to your LAN zone if you were both 1) using private IPs on your firewall's Public interface because your ISP is doing source NAT, and 2) needing some other device on the network between your firewall and ISP's device (the Public zone according to the firewall, but the private side according to the ISP's NAT device) to the firewall's LAN zone.
If you're interested in a more comprehensive BOGON list than just RFC1918, I'm a fan of CYMRU's Full Bogon list, which also includes public IP ranges not yet allocated by IANA. It can be used as an external dynamic list (EDL) on the Palo Alto firewall.
https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/
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!
