Allow the countries your users actually connect from, then deny other countries at the rule that protects the public VPN address.
Open the firewall instructionsAllow only the countries your users connect from, and apply that restriction where the VPN listens: a FortiGate local-in policy or SSL VPN source setting, a Palo Alto security rule for the GlobalProtect portal and gateway, or SonicWall Geo-IP Filter on the SSLVPN access rule. Keep exceptions for approved travelers.
Testing a block list? Download the free 200-entry sample. No signup is required.
Traffic sent to a FortiGate interface is local-in traffic. A normal forward firewall policy does not control it.
In FortiOS 7.6, go to Policy & Objects > Addresses, create an address, set Type to Geography, and select a country. Repeat this for every approved country, then place the objects in an address group.
config firewall address
edit "Allowed-US"
set type geography
set country "US"
next
end
config firewall addrgrp
edit "VPN-Allowed-Countries"
set member "Allowed-US"
next
endFortinet says geography addresses are populated from its geography IP database. Confirm that the address assigned to a real user is mapped as expected before enforcing the rule.
For FortiOS versions that still provide SSL VPN tunnel mode, set the approved geography group as the SSL VPN source and leave negation disabled. Fortinet documents these settings in the SSL VPN CLI and security best-practice guide.
config vpn ssl settings
set source-address "VPN-Allowed-Countries"
set source-address-negate disable
endReview each SSL VPN authentication rule too. Fortinet warns that an authentication rule with its own source address can affect how the global source restriction is applied.
On FortiOS 7.6.0 and later, go to Policy & Objects > Local-In Policy. On earlier releases, configure local-in policies in the CLI. Enabling Local In Policy under System > Feature Visibility only displays them.
Create an allow rule for the approved-country group, followed by a deny rule for all other sources. Scope each pair to the WAN interface, the firewall's public destination address, and only the required service. Fortinet lists UDP 500 and UDP 4500 for standard IPsec negotiation. Use the configured TCP port for Agentless VPN or an older SSL VPN deployment, and the actual management services you expose.
config firewall local-in-policy
edit 10
set intf "wan1"
set srcaddr "VPN-Allowed-Countries"
set dstaddr "FGT-PUBLIC-IP"
set action accept
set service "IKE"
set schedule "always"
next
edit 11
set intf "wan1"
set srcaddr "all"
set dstaddr "FGT-PUBLIC-IP"
set action deny
set service "IKE"
set schedule "always"
next
endCreate separate, narrowly scoped rules for administrative HTTPS or SSH. Do not substitute ALL for the service unless you intend to affect every FortiGate service on that interface.
In FortiOS 7.6, configure local-in logging in Log & Report > Log Settings. In the CLI, use set local-in-policy-log enable under config log setting and set logtraffic enable on each local-in policy (FortiOS 7.6.6 guide). Denied requests appear under Log & Report > Local Traffic. A user-defined local-in rule has its own policy ID.
Test from an approved source and a controlled source outside the allowed countries. Confirm the source country, destination, service, action, and local-in policy ID in the log.
Match the public source region in the security rules that protect the GlobalProtect portal and gateway address.
Go to Policies > Security. Create an allow rule above the deny rule and select the approved country, such as US, in the Source Address field. Palo Alto Networks security rules support country-based source enforcement without a custom address object.
Limit the destination to the exact portal or gateway public address. For a portal or external gateway on an untrust interface, both the source and destination zone are normally that untrust zone. If you terminate GlobalProtect on a loopback or use destination NAT, select the zones and addresses that match that design; security policy uses the post-NAT destination zone and original destination address.
Place two explicit rules above broader intrazone rules:
GlobalProtect uses TCP 443 for portal, gateway, and SSL tunnel communication. A gateway also uses UDP 4501 when GlobalProtect IPsec is enabled. Commit the rules after checking that approved travelers and mobile users are represented by the allowed regions or an explicit exception.
Use a controlled source address and the PAN-OS policy-match test. This example checks TCP 443; replace both addresses with the actual client and GlobalProtect destination:
test security-policy-match application ssl source 198.51.100.25 destination 203.0.113.10 destination-port 443 protocol 6Then open Monitor > Logs > Traffic and filter on the portal or gateway destination. Confirm the source region, matched rule, application, destination port, and action. Palo Alto Networks also documents using the portal or gateway IP as the destination when finding a client's public IP and geographic source before tunnel establishment.
In SonicOS 7 classic mode, use firewall-rule-based filtering so the country restriction applies to the SSLVPN access rule.
Go to Policy > Security Services > Geo-IP Filter. On the Settings tab, enable Block connections to/from countries selected in the Countries tab and select Firewall Rule-Based Connections. On the Countries tab, select the countries to block.
Geo-IP Filter is a licensed security service. Check its status under Device > Settings > Licenses and confirm that the country database status is healthy before relying on the rule.
Go to Policy > Rules and Policies > Access Rules. Edit the WAN-to-WAN rule whose destination is the WAN interface address and whose service is SSLVPN. Under Security Profiles, enable Geo-IP Filter. Choose Global to use the country selection from the Geo-IP Filter page, or Custom to set the allowed and blocked countries for this rule.
Use the Geo-IP Exclusion Object for approved public IP addresses that must bypass a country block. Keep the exception narrow.
SonicWall's Custom List corrects the country assigned to an IP address. If you enable it, select Override Firewall Countries by Custom List when the custom assignment must take precedence over SonicWall's database. It is not a substitute for the country selection on the SSLVPN rule.
Under Policy > Security Services > Geo-IP Filter > Settings, enable logging. Test from approved and blocked locations, then confirm the event in the firewall logs.
A country rule reduces exposure. It does not establish who is behind an allowed-country IP address.
An attacker can route through a VPN, residential proxy, or hosted system whose public address is mapped to an allowed country. SonicWall explicitly warns that a VPN can make traffic appear to come from a permitted country. For the distributed version of this problem, see how residential proxy VPN attacks work.
Country databases can also assign some ranges incorrectly. SonicWall provides its custom list for correcting a false country assignment, and all three vendors provide ways to inspect the region or country recorded for traffic. Test the public addresses used by employees, contractors, administrators, and approved travel before enforcement.
Geo-blocking also creates an operational rule: a legitimate user who travels outside the allowed countries will be denied unless you add a narrow exception or temporarily approve the destination.
For a control-by-control comparison, see ThreatListPro versus geo-blocking.
Each control stops a different part of VPN password attacks.
| Control | What it stops or reduces | What still gets through | Where to start |
|---|---|---|---|
| Country restriction | Connections whose public IP maps to a blocked country | Attackers using an address mapped to an allowed country | The VPN's local-in, security, or SSLVPN access rule |
| MFA | A password alone being enough to complete a login | Login attempts, account lockouts, and attacks against MFA itself | The VPN authentication source or identity provider |
| Login lockout | Repeated failures that cross the configured source or account threshold | Distributed attempts that stay below that threshold | The firewall and authentication provider |
| Known-attacker block list | Traffic from an IPv4 address or CIDR already present in the list | A new IP's first attempt and IPv6 traffic | The firewall rule in front of the VPN service |
Use country restrictions, MFA, and the vendor's login controls first. When the attacker list is too long to maintain by hand, add a dynamic block list (Palo Alto calls it an External Dynamic List, or EDL; FortiGate calls it a threat feed). See what an external dynamic list is for the details.
ThreatListPro covers 5.4M+ IPv4 addresses from real attacks on live production Palo Alto GlobalProtect VPN portals in the US. It is checked for new attackers every 6 hours. Use the existing firewall IP-blocking guide and the platform protection guide instead of copying setup steps from this reference page.
A new IP's first attempt still arrives. ThreatListPro is IPv4 only, and it does not stop every brute-force or password-spraying attempt. CIDR ranges include addresses that did not each attack, so check your own users' source IPs first and allow-list trusted networks where needed.
A block list does not replace MFA, lockout controls, country restrictions, current firewall software, authentication monitoring, or incident response. See how VPN brute force attacks work for the full defense stack.
Create a US geography address, place it in an approved-country group, and use that group as the allowed source. For traffic sent to the FortiGate itself, use an allow local-in policy followed by a deny rule for the same VPN or management service. On older SSL VPN deployments, the group can be set under config vpn ssl settings with source-address negation disabled.
A normal firewall policy handles traffic forwarded through the FortiGate. SSL VPN, Agentless VPN, IPsec negotiation, and administrative access are addressed to the FortiGate itself, so they are local-in traffic. Restrict that traffic with SSL VPN source settings or a local-in policy scoped to the listening interface, destination, and service.
Create an allow security rule with the US as the source region, the portal or gateway public address as the destination, and the required GlobalProtect services. Put a deny rule for any other source immediately below it and above broader intrazone rules. Include approved traveler exceptions before the deny rule.
GlobalProtect uses TCP 443 for communication with portals and gateways and for SSL tunnels. A gateway also uses UDP 4501 when GlobalProtect IPsec is enabled. Match only the public portal or gateway address and the services your deployment uses.
Check that Geo-IP is licensed, enabled, and has downloaded its country database. If Firewall Rule-Based Connections is selected, Geo-IP must also be enabled on the WAN-to-WAN SSLVPN access rule. Review the exclusion object and custom-list overrides, enable logging, and test more than one connection from the same controlled source.
It reduces attempts from IP addresses mapped to blocked countries, but it does not stop an attacker using a VPN, proxy, or hosted address in an allowed country. Pair it with MFA, appropriate lockout controls, monitoring, and a known-attacker list. A new address can still make its first attempt.
ThreatListPro covers 5.4M+ IPv4 addresses from real attacks on live production Palo Alto GlobalProtect VPN portals in the US and is checked for new attackers every 6 hours. Monthly is $9.99 with a 14-day free trial and no card needed.
Start a 14-day free trial Or test 200 entries first: free, no signupUse the platform guide when you are ready to add a dynamic list of known VPN attack sources.
Continue with the attack explanation, comparison, and firewall setup guides.