Create firewall rule for internet access without using any as destination

[Nelly]

Hi, I am tightening up our rulebase for some new internal network that I have created

I have hit the issue that I several rules that allow certain hosts internet access via having ANY in the destination.  This now affects my new subnets as a possible way to access them as matching the ANY destination.

Does anyone have a clever suggestion of a way around this without rulebase changes such as a block rule before all affected rules hits that first then gets denied ( this has ramifications for rule ordering for the allowed accesses )?

The internet access need to be unrestricted hence any so restricting that is not an option

May Thanks

Neil

Clustered Checkpoint R81.10 Take 150 (x2 devices)

[Alex-]

There was a discussion about defining Internet a few years back.

https://community.checkpoint.com/t5/Management/Properly-defining-the-Internet-within-a-security-poli...

So you have many ways to approach this. Personally, I tend to use private or internal networks in a group and negate them as destination, but you could use the Internet object or any other discussed method depending on your topology.

[Lesley]

I do the same with the negate method

[emmap]

You can do it a little differently to achieve the same thing by creating a 'Group With Exclusions'. Attached are how I did it. You can add any public IP ranges that are also part of your internal/DMZ network to the 'except' group as well. This way the group itself is 'anything except the defined IP ranges' rather than negating the whole destination cell in the rule.

[Bob_Zimmerman]

For IPv4, Internets_Except should probably also contain

• 0.0.0.0/8 - reserved for the local network
• 100.64.0.0/10 - private network for CG NAT (RFC 6598)
• 127.0.0.0/8 - loopback
• 169.254.0.0/16 - link local
• 192.0.0.0/24 - private network (Dual Stack Lite; RFC 6333)
• 192.0.2.0/24 - reserved for documentation (RFC 5737)
• 192.88.99.0/24 - reserved (RFC 7526; originally for 6to4 relay; while that has been deprecated, the block has not been released)
• 198.18.0.0/15 - private network for benchmarking performance (RFC 2544)
• 198.51.100.0/24 - reserved for documentation (RFC 5737)
• 203.0.113.0/24 - reserved for documentation (RFC 5737)
• 224.0.0.0/4 - multicast (there's also a multicast network reserved for documentation: 233.252.0.0/24, RFC 6676)
• 240.0.0.0/4 - reserved experimental (RFC 3232)

None of these destinations are allowed to refer to real things on the public Internet.

[the_rock]

Super easy, this is what you do. Edit policy layer, then network layer, enable urlf blade, save, publish, add Internet object as dst, publish, install policy.

Thats it 🙂

Forgot to add, make sure urlf + appc blades are enabled on gateway object.

Andy

[PhoneBoy]

Why not use ExternalZone?
This should be associated with your external interface(s).
Available for R8x gateways.

[Nelly]

VPN-s go via internet, if i use external zone will this be affected ?

[the_rock]

If its tied to your external interface, then it wont work in such scenario. 

Andy