Properly defining the Internet within a security policy

[Network_Anderso]

I am interested in Method 5 but I don't fully understand it. I understand these are RFC 1918 and addresses can be added here but I am unsure how or when they are referenced. How are these network negated or when does the firewall observe addresses listed in this global property.

Thank you all

[Ilmo_Anttonen]

Hi,

This method is not related to the "Non Unique IP Address Ranges" defined under global properties.

To use this method you define three network objects with the networks 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Then you either add them to a network group and call it for instance G_RFC1918. Now you place this group or the three networks to the rule source or destination columns and then right-click the object in the column and select "Negate Cell". 

That's all!

[Network_Anderso]

Thanks, so to be clear for my own understanding, if my outbound rule says source (internal network) destination RFC1918 group(negate), any service,  action accept

This will allow all IP traffic outbound from my LAN to the Internet except traffic to the negated group.

[Ilmo_Anttonen]

Yes that would allow all traffic to the routable Internet, but would stop uninteded traffic from accessing your local networks..

If you want to allow the whole Internet access to your website I suppose that you would put the negated RFC1918 group in the source column and the website IP-address and relevant ports in destination and services columns.

/ Ilmo

[Hugo_vd_Kooij]

Just for those brave enough, mehod 6:

And you might want to make it more complex if you want to exclude your Externe IP range for example.

Or if you have a need for Multicast traffic. (Which is a book by itself 😉

[Network_Anderso]

This may be a foolish question but really wanted to know. If I have a rule inbound from the internet that is specifying source as (All_Internet) - to a DMZ web server, what happens when when a source address comes in from an IPV6 address? It seems like All_Internet pre-defined object only encompasses IPv4 address. How does the firewall address the IPV6 source address when my rule basically says only allow this 0.0.0.0 - 255.255.255.255.

Thanks again, really helpful stuff

[Kristof_Vermael]

In my opinion, option 5 is the best (and only option) you can/should use.

You often have site 2 site VPN's with public IP addresses in the encryption domain, and these need to be excluded from the 'internet' object as well.Creating a group 'all_customerX_networks' and negating this in the policy never fails.

The natting policy would then contain a rule 'all_customerX_networks' to 'all_customerX_networks' -> no nat.  Above, you can put all internal natting, below, you should put all Hide NAT rules to internet.

The moment security zones are permitted in the NAT rule, I will switch to this, but for now, I will stick to negating this object.

[Ilmo_Anttonen]

Exactly. Depending on the size of the network I usually create a G_RFC1918 or in case of larger networks with several S2S VPNs a G_NoNAT where I place all customer networks and network groups. I know it's probably not best practice to have groups in groups from a performance perspective but, if you have the juice, you can have fewer rows in the security policy and NAT policy 

[Tomer_Sole]

Ilmo Anttonen wrote:

I know it's probably not best practice to have groups in groups from a performance perspective

It's actually fine, there's no performance impact when using large groups or nested groups.

In case you make multiple nesting levels for a group, it might affect your ease of management at some point, with unexpected side effects when different users will reuse and edit the little groups that are used by the larger groups.

[Ilmo_Anttonen]

That was news for me. Thank you Tomer!

[Petr_Hantak]

For me is still method 5 in top use. In some special cases we are using method 3 as well but groups with exclusion have many problems. It is not also suitable for NATs.

Method 6 is interesting way and I hope that once we'll be "brave enough" as Hugo van der Kooij‌ mentioned to make it real on some bigger rulebase/topology case.

[SChalhoub]

Great explanation.

[MKIT_NMG]

Great Explanation... Thanks...