Internal Access Denied Despite Country-Based Restrictions

3 replies
2676 views

Dear Community,

I'm grappling with a FortiGate firewall configuration dilemma. I've set up a web server with country-based access restrictions, allowing only certain countries. While this works for external access, internal connections from the local network are being denied. Specifically, attempts from an internal IP (e.g., 192.168.0.50) to the server (e.g., 192.168.0.10) are blocked by the policy, configured with the source set to WAN and destination to LAN.

To resolve this, I'm contemplating adding the internal IP range to the list of allowed countries. Notably, the policy from internal to the internet has NAT enabled.

My question is whether including the entire internal IP range in the list of allowed countries is a advisable workaround, or if there's a more nuanced approach to facilitate internal access while preserving external restrictions.

I'd appreciate any insights or alternative suggestions from the community.

Thank you for your expertise.

FortiGate

saleha

Staff & Editor

Hello Mair,

Thank you for reaching out. Internal private address range should not match a geoip address object as these private addresses cannot be routed and they are not be listed under any country. If you are performing hair pinning configuration where internal users behind the same firewall as the server have to go to the internet first before they reach the server using the vip address that might explain the issue. I would recommend troubleshooting the issue using debug flow and sniffer commands in different cli sessions:

# diag de reset

# di de flow filter addr x.x.x.x ---- dst address where traffic is blocked

# di de flow filter port <dst port if applicable>

# di de flow show function en

# di de flow trace start 10 ----- number of packets to be recorded

# di de console time en

# di de en

# di sniffer packet any "host x.x.x.x and port <dst port>" 4 0 l

Thank you,

saleha

MairAuthor

Visitor III

thank you very much for your fast reply!

2024-01-31 14:33:45.392701 internal in 192.168.0.53.61158 -> 80.x.x.x.443: syn 3802687125
2024-01-31 14:33:46.398426 internal in 192.168.0.53.61158 -> 80.x.x.x.443: syn 3802687125
2024-01-31 14:33:47.415662 internal in 192.168.0.53.61158 -> 80.x.x.x.443: syn 3802687125
2024-01-31 14:33:48.465657 internal in 192.168.0.53.61158 -> 80.x.x.x.443: syn 3802687125
2024-01-31 14:33:49.410174 internal in 192.168.0.53.61158 -> 80.x.x.x.443: syn 3802687125

this is what i get when i try to access the site. (note that i masked the public IP's)

As you mentioned, the clients are behind the same port as the server is. Most clients access the server using DNS, therefore with a public IP. They try to go to the internet, but never exit through the WAN. When i enable the log for the server's policy, i can see that the request is denied. The source is a local IP and this does not match the source (country, i.e. public IP) of the policy. As already said, when I add the local IP range to the source of the policy, i have access. But adding the local IP range to a policy from WAN seems like a dirty hack.