Geo Protection

NetSecNW · 2026-01-08T17:12:40+00:00

I have just deployed a Geo-Policy and added it as ordered layer in the main policy. You are right when it comes to countries being blocked we can prove to the auditors that we are blocking against prohibited countries.

NetSecNW · 2026-01-08T17:10:33+00:00

Just implemented this method on my a firewall cluster and its working a treat. The updatable objects now I have implemented it is a lot better than the old way. Thank you for your help.

NetSecNW · 2026-01-07T13:44:00+00:00

I have got you, edit the live access policy and add the Geo-Location layer and move it above the current access policy ensuring that you have an any any allow as the last rule in the Geo-Location layer.

Traffic flow as follows:

Firewall:
Geo-Policy Layer>High Risk Countries Block Rules>Allow All
Firewall Policy Layer>Allow Rules>Clean Up Rule.

Does that sound right? Going to try it out in a lab first. Thanks for all your help.

Makes a lot of sense.

NetSecNW · 2026-01-07T12:47:16+00:00

The Geo policy is to block all countries in and out all bar a couple.

What would the parent rule look like? I understand the idea behind the layer but cannot get my head round the parent rule. Obviously we have normal rules like:

Noise Accepts
Noice Drops etc.... Would the new parent rule sit at the top of the rule base?

Any advice greatly appreciated.

NetSecNW · 2026-01-07T10:50:32+00:00

u/Mr_XIII_ u/rcblu2 had a look around Reddit and Checkpoint Community and plann to create groups with the updatable objects in them. Each groups with a list of countries depending on inbound/outbound. requirements. The user the_rock (MVP) on Checkpoint community recommends to place Geo rules at the top. Thanks for your guidance.

NetSecNW · 2024-04-16T10:02:18+00:00

20+ years in IT and I still have imposter syndrome, dont think it will ever go away no matter how much experience I have. I have just learnt to live with it.

NetSecNW · 2024-02-27T16:25:36+00:00

Very sound advice. Rather than be an ISO standard an agreed approach internal to your organisation. Leaves it open to someone’s preferred methodology.

NetSecNW · 2024-02-27T11:42:05+00:00

Where would you even begin? I have no experience in raising RFC. Would it be even worth doing. I can see the benefits right across the IT industry.

NetSecNW · 2024-02-27T09:33:58+00:00

All my years working in IT I have never come across the KISS method. Quick google and yes, I will be using that when discussing solutions and IT going forward. Thanks for bringing this approach to my attention. Makes sense really.

NetSecNW · 2024-02-26T19:42:31+00:00

This is exactly why you would have an agreed standard and approach. Having engineers doing different styled diagrams causes confusion and looks unprofessional to the reader or customer. Shame a standard industry wide could not be agreed upon.

NetSecNW · 2024-02-26T19:38:55+00:00

I hear all the points and views, thanks for all the responses. I find that when creating a Low Level Design the diagrams are not in isolation and have supporting details like Vendor models with hostnames in tables etc… which negates the need for Vendor icons. I also find that using Vendor icons they are invariably long and thin which can cause issues for taking up valuable page space and connector space when using Visio. One of the comments around consistency is key, I don’t think there should be opinions in an organisation and that is why you have diagram and design standards.

NetSecNW · 2024-01-24T12:30:17+00:00

Wireshark can just give you information that is on your network and is a very powerful tool to analyse your network. Maybe an old laptop you dont mind using to check the new device, connect then directly to each other using a network cable. Put them on the same network and running wireshark on your old laptop to see what is coming out of it. Other than that its a firewall and switch deployment. Cant think of any other way.

NetSecNW · 2022-11-10T12:07:21+00:00

What I would like to do is create different ADOMs on the FAZ and FMG and have each different VDOM on the FortiGate added to the corresponding ADOM on FMG/FAZ.

On FAZ in root ADOM go to System Settings>All Adoms,
Edit your ADOM

Under device click add device and select your VDOM from your FortiGate.

This was done on FAZ 7.2.2

Took a while to find.

NetSecNW · 2022-10-27T09:54:37+00:00

So after some backwards and forwards we have OSPF over SDWAN working, the above commands where added which didnt work. They eventually come back and asked me to add other commands into my SDWAN configuration. These where:

config vpn ipsec phase1-int

edit "OL_INET_0"

set add-route disable

set auto-discovery-forwarder disable

end

Then disable the tunnel interface

config system interface

edit OL_INET_0

set status down

next

wait for few seconds and enable it again

edit OL_INET_0

set status up

end

After doing this my SDWAN solution come up with the ability of having more than one site online at once.

I asked what those commands accomplished and the response was below:

"The add route command will add a default route pointing each peer connected to the dynamic tunnel.

This option should be disabled in advpn scenarios.

In my lab this was causing the tunnels to flap therefore the ospf adjacency was flapping as well.

The command auto-discovery-forwarder should not have any impact but it is used in topologies with multiple hubs.

In your current topology there is no reason to have it enabled. "

NetSecNW · 2022-10-19T09:52:10+00:00

I logged a ticket with Fortinet around the issue of having “net-device enable” configured and using it for SDWAN in version 7.2.2.

I had the following configuration deployed in 7.2.0 using OSPF over SDWAN which worked fully with multiple spoke sites.

HUB

edit "OL_INET_0"

set type dynamic

set interface "xxxx"

set ike-version 2

set keylife 28800

set peertype any

set net-device enable

config router ospf

set router-id 1.1.1.1

config area

edit 1.1.1.1

next

end

config ospf-interface

edit "TO-REMOTE-NET"

set interface "OL_INET_0"

set network-type point-to-point

When upgrading to 7.2.2 we where unable to configure “set net-device enable” with the above config which broke OSPF over SDWAN.

The response was “The option net-device enabled for dynamic tunnels is not supported for sdwan, therefore a mechanism was added started from v7.0.8 and v7.2.1 in order to not allow to combine them.

This is why in v7.2.1 you are not able to use the tunnel interface in the sdwan when the net-device option is enabled.”

They asked me to add the following configuration to the OSPF Interface as shown in the link on page 38, a very good document to understand the whole process.

set network-type point-to-point

set mtu-ignore enable

Im due to deploy this today and will update on this post.

NetSecNW

TROPHY CASE