Public to Public RFC 1918 blocks

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Public to Public RFC 1918 blocks

L2 Linker

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 

 

2 accepted solutions

Accepted Solutions

Cyber Elite
Cyber Elite

@shafi021,

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. 

View solution in original post

L4 Transporter

@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/

View solution in original post

2 REPLIES 2

Cyber Elite
Cyber Elite

@shafi021,

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. 

L4 Transporter

@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/

  • 2 accepted solutions
  • 4662 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!