PORTALPILOT / Fortinet Knowledge Base Open PortalPilot Simulator →
DNAT & VIP Troubleshooting

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

⚡ Quick Answer (AEO Summary)

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.

Confused by raw FortiGate debug output? Paste debug logs into PortalPilot to extract the root cause in plain English with 1-click remediation scripts.
Diagnose My VIP →

🔍 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:

config system global
  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.