How to Fix FortiGate Virtual IP (VIP) Port Forwarding Not Working
Last Verified: November 2026 • Applies to FortiOS 7.0, 7.2, 7.4 & FortiPortal Managed Tenants
To fix FortiGate Virtual IP (VIP) port forwarding, verify three critical elements: 1) The VIP object has port forwarding enabled with matching external and mapped ports, 2) The incoming firewall policy explicitly selects the VIP object as the Destination Address (not “all” or the internal IP), and 3) The internal server’s default gateway points back to the FortiGate, or Source NAT is enabled to prevent asymmetric return drops.
🔍 Step 1: Verify the Virtual IP (VIP) Object Configuration
In FortiOS, a Virtual IP acts as a Destination NAT (DNAT) mapping table entry. The object must correctly define the public IP (or 0.0.0.0 for interface-bound VIPs) and the target private server address.
# Check VIP definition in FortiOS CLI
show firewall vip "Web-Server-VIP"
# Example of a correctly configured Port-Forwarding VIP:
config firewall vip
edit "Web-Server-VIP"
set extip 203.0.113.10
set extintf "wan1"
set mappedip "192.168.10.50"
set portforward enable
set protocol tcp
set extport 443
set mappedport 443
next
end
Important: If your public IP is dynamic (DHCP/PPPoE), set set extip 0.0.0.0 and bind it to the WAN interface with set extintf "wan1".
🛡️ Step 2: Ensure Firewall Policy Targets the VIP Object
This is the single most common mistake in FortiOS administration. In FortiGate, firewall policies evaluate the pre-NAT destination address. You must select the VIP object itself as the dstaddr, not the internal server address object.
# Correct Firewall Policy for Inbound VIP Traffic
config firewall policy
edit 10
set name "WAN-to-WebServer-VIP"
set srcintf "wan1"
set dstintf "internal"
set action accept
set srcaddr "all"
# CRITICAL: Select the VIP object, NEVER the private server IP
set dstaddr "Web-Server-VIP"
set schedule "always"
set service "HTTPS"
# Outgoing NAT: keep disabled so server logs real client IP
set nat disable
next
end
⚠️ Step 3: Eliminate Admin Port Conflicts & Return Routing Drops
Conflict 1: FortiGate HTTPS Admin Port Clashing
If FortiOS Administrative Access is listening on port 443 or port 80 on the WAN interface, the FortiGate management daemon claims the packet before the VIP engine processes it. Check under System > Settings or run:
set admin-sport 8443
end
Conflict 2: Server Default Gateway & Asymmetric Routing
If the internal server (e.g. 192.168.10.50) has a default gateway pointing to a different router (such as an internal core switch or ISP router), the return SYN/ACK packet bypasses the FortiGate. The external client drops the connection because the return packet does not arrive from the WAN VIP IP.
Remedy: Either point the server's default gateway to the FortiGate interface, or enable Source NAT (set nat enable) on the firewall policy so the server responds directly back to the FortiGate's local IP.
🔬 Step 4: Real-Time FortiOS Packet Flow Tracing
Execute a flow trace on the FortiGate CLI while initiating an external connection to verify whether DNAT translates the packet or if a firewall policy drops it:
# Clear prior debug filters
diagnose debug reset
diagnose debug flow filter clear
# Set destination to your external WAN IP and port
diagnose debug flow filter daddr 203.0.113.10
diagnose debug flow filter dport 443
# Enable verbose flow trace
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable
# Look for these key indicators in the output:
# "find a rule for NAT to 192.168.10.50:443" -> DNAT Success!
# "Denied by forward policy check" -> Policy mismatch (check step 2)
# When finished:
diagnose debug disable
diagnose debug reset
❓ Frequently Asked Questions
Why is my FortiGate VIP port forwarding not working?
The most common reason FortiGate VIP port forwarding fails is that the firewall policy's Destination Address is set to 'all' or the server's private IP rather than the VIP object. In FortiOS, DNAT is only triggered when the incoming policy explicitly matches the VIP object as its destination.
Should NAT be enabled in a FortiGate policy using a VIP?
In most standard inbound DNAT policies, Outgoing NAT (Source NAT) should remain disabled so the internal server sees the original client source IP for logging. However, if the destination server does not use the FortiGate as its default gateway, Source NAT (or NAT with an IP pool) must be enabled to prevent asymmetric return routing drops.
What causes port 443 VIP forwarding to fail on FortiGate WAN?
If FortiOS HTTPS Administrative Access is listening on port 443 on the incoming WAN interface, the FortiGate kernel intercepts port 443 for its management GUI before VIP DNAT can process the packet. To fix this, change the FortiGate HTTPS admin port under System > Settings to a non-standard port (e.g., 8443) or disable administrative access on the external interface.
Solve Fortinet Problems Fast with PortalPilot
PortalPilot translates raw FortiGate, FortiOS, and FortiPortal logs into plain-English root causes and change requests. 100% on-device zero-trust execution.