Whitelist an External IP in FortiGate Firewall

To whitelist an external IP address in a FortiGate firewall means creating a policy that explicitly permits traffic from that IP, bypassing stricter rules. This guide shows you how to create an address object for the external IP and then build a security policy that allows it, either before other policies or as a specific rule. You’ll need administrative access to the FortiGate web interface (GUI) or CLI.

What You’ll Need

• Administrator credentials for the FortiGate (read-write access).
• The external IP address (IPv4 or IPv6) you want to whitelist.
• Knowledge of the destination interface (e.g., which internal network the traffic should reach).
• Optional: the port or service (e.g., TCP 443) if you want to restrict the whitelist to specific traffic.

Step-by-Step

1. Log in to the FortiGate web interface. Open your browser and navigate to the FortiGate’s management IP (e.g., https://192.168.1.99). Enter your admin username and password.
2. Create an address object for the external IP. Go to Policy & Objects > Objects > Addresses. Click Create New. Enter a name (e.g., “Whitelist_IP_203.0.113.5”). Set Type to Subnet (or IP Range if you need a range). For Subnet, enter the IP address and subnet mask (e.g., 203.0.113.5/32 for a single IP). Click OK.
3. Create a security policy for the whitelist. Go to Policy & Objects > Firewall Policy. Click Create New. Under Incoming Interface, select the interface that receives the external traffic (e.g., WAN1). Under Outgoing Interface, select the destination interface (e.g., DMZ or Internal).
4. Set the source to the whitelist address. In the Source field, click the + to add the address object you created. You can also add the address by typing its name. Leave the source as the single address object; do not add “all” unless you intend to whitelist all sources.
5. Set the destination. In the Destination field, select the destination addresses (e.g., the internal server’s IP). You can use “all” if you want to allow access to everything on the outgoing interface, but it’s safer to specify.
6. Configure the service. Under Service, select the service(s) you want to whitelist. For example, if you’re whitelisting for remote desktop, choose RDP (TCP 3389). If you’re not sure, use ALL for now, but be aware that this opens all ports.
7. Set the action to ACCEPT. Under Action, select ACCEPT. This is the key step that actually whitelists the IP.
8. Enable logging (optional but recommended). Under Logging Options, enable Log All Sessions or at least Log Violation Traffic. This helps with troubleshooting later.
9. Place the policy in the correct position. After creating the policy, it appears in the policy list. FortiGate evaluates policies top-down. To ensure your whitelist is effective, it must be placed above any deny policies that would otherwise block the traffic. Drag the policy to the top of the list, or use the up arrow on the policy row. If you have a default deny-all at the bottom, your whitelist policy must be above it.
10. Save and apply. Click OK to save the policy. The changes are applied immediately. No reboot is needed.
11. Test the whitelist. From the external IP, try to access the destination service. If it works, you’re done. If not, check the policy order and the address object.

Common Mistakes

• Wrong policy order: Placing the whitelist policy below a deny-all rule. FortiGate stops at the first matching policy, so if a deny matches first, the whitelist never gets evaluated.
• Incorrect subnet mask: Using /24 instead of /32 for a single IP. This whitelists an entire range, which might be a security risk.
• Source/Destination confusion: Mixing up the incoming and outgoing interfaces. The source should be the external IP’s interface (usually WAN), and the destination should be the internal network.
• Forgetting to enable the policy: If the policy status is disabled (grayed out), it won’t work. Ensure the policy is enabled (green checkmark).
• Using the wrong service: If you whitelist only TCP 443 but the service uses a different port, the traffic will be blocked. Double-check the service port.

Tips

• Use address groups: If you need to whitelist multiple IPs, create an address group and add the individual address objects to it. Then use the group in the policy source.
• Name objects clearly: Use descriptive names like “Allow_IP_203.0.113.5_To_WebServer” to make management easier.
• Schedule the whitelist: You can attach a schedule to the policy if you only want the whitelist active during certain hours (e.g., business hours).
• Use the CLI for bulk changes: If you have many IPs, using the CLI with config firewall address and config firewall policy can be faster.
• Test with a temporary policy: If you’re unsure, create the policy with a short schedule (e.g., 30 minutes) to test before making it permanent.

Troubleshooting

If the whitelist isn’t working, follow these steps:

1. Check the policy order: Go to the policy list and verify that the whitelist policy is above any deny policies. If not, move it up.
2. Check the address object: Verify that the IP address and subnet mask are correct. A typo in the IP will cause the whitelist to not match.
3. Check the service: If you specified a service, ensure that the port matches the actual service. For example, if you’re using RDP, the port is 3389, not 443.
4. Check the logs: Go to Log & Report > Traffic Log. Look for entries from the external IP. If you see a deny log entry, the policy is being blocked. If you see an accept log, the traffic is allowed.
5. Check the interface: Make sure the incoming interface is correct. If the traffic comes in on a different interface (e.g., a VLAN), the policy won’t match.
6. Check the destination: If you specified a destination address, ensure it matches the server’s IP. If the server has multiple IPs, you might need to add them all.
7. Check for NAT or VIP issues: If you have Virtual IPs (port forwarding) for the service, the whitelist policy must be placed before the NAT policy, or the source IP might be translated. In some cases, you may need to create a policy for the VIP’s external IP.

Frequently Asked Questions

Can I whitelist an IP range instead of a single IP?

Yes. Create an address object with Type IP Range and enter the start and end IPs. Or use a subnet mask like /24 for a whole range.

What is the difference between an address object and a policy?

An address object is a named definition of an IP or range. A policy uses that object to allow or deny traffic. You must create the address object first, then reference it in a policy.

How do I whitelist an IP for all services?

In the policy, set Service to ALL. This allows all ports and protocols from that IP.

Why is my whitelist policy not working even though it’s on top?

Check if there is a VIP (virtual IP) that matches the destination. If the destination is a VIP, the policy must be placed before the VIP’s NAT policy. Also, ensure the source interface is correct.

Can I whitelist an IP using the CLI?

Yes. Use config firewall address to create the address, then config firewall policy to create the policy. Example: edit 0 then set srcaddr "Whitelist_IP" and set action accept.

How do I remove a whitelist?

Delete the policy that allows the IP, or delete the address object. If you delete the address object, the policy will become invalid and will not match.

Related

• Open Source Authenticator Apps: Top Alternatives
• Grounded Sci-Fi Mind-Bending Movies That Stay on Earth
• Smart Relays vs Smart Bulbs: Why People Switch