Technical Tip: Configure port forwarding using FortiGate VIPs

[guptar]

Description	This article describes port forwarding using FortiGate Virtual IPs.
Scope	FortiGate.
Solution	To forward TCP or UDP ports received by the FortiGate external interface to an internal server, follow two steps: Create a Virtual IP and enable Port Forwarding. Create a firewall policy and add the Virtual IP. This example describes how to configure port forwarding to allow RDP access to an internal server on port 3389. To add a virtual IP that forwards RDP packets, follow the steps below. For v6.0.x, v6.2.x, v7.0.x, v7.2.x, v7.4.x, v7.6.x navigate to Policy & Objects -> Virtual IPs. Select Create New. Add a name for the virtual IP. Select the External Interface. This will typically be the interface that connects the FortiGate to the Internet. (Can leave as 'any'). Set the External IP Address/Range. The following can be used: The FortiGate unit's public IP. If there is a cable or DSL connection with a dynamic IP, it is possible to use 0.0.0.0. (Cannot use 0.0.0.0 when interface is 'any').  If the ISP provides a block of IPs that route to the FortiGate external interface, it is possible to add one of these IPs here. Set the Mapped IP Address to the internal IP address of the server. Select Port Forwarding. Set the protocol to TCP. Set External Service Port and Map to Port. For this example, the RDP service uses port 3389. Set both the External service port and the Map to Port to 3389. Select OK. All that remains is to define a firewall policy that accepts RDP traffic from the Internet and forwards it to the internal server. To add a firewall policy with a virtual IP: In v6.0, go to Policy & Objects -> IPv4 Policy. In v6.4.x, v7.0.x, v7.2.x, v7.4.x, v7.6.x Navigate to Policy & Objects -> Firewall Policy. Select Create New. Set the Source Interface to the WAN/Internet interface. Set Source Addresses to all. Set Destination Interface to internal. Set the Destination Address to the name of the Virtual IP created previously. Usually, the remainder of the options in this firewall policy do not need to be changed. For example, the Service can remain as ANY, because the virtual IP only forwards packets using port 3389. NAT can be enabled or disabled based on the network requirements. Some servers might not respond to RDP connections from a different network due to a Windows/host-based firewall. NAT must be enabled in these cases. Select OK. Note: NAT is not mandatory when creating a VIP. ONLY if the behavior wants to be changed with the source and specific port, like in the example provided above. Sometimes NAT needs to be enabled for VOIP traffic The port range can be added for port forwarding in the virtual IP as below: Make sure to add this port range as a service in the firewall policy as well. Note: If the 'External service port' and 'Map to IPv4 port' are different, both ports must be specified in the 'Service' field of the firewall policy (if it is not set to 'any').    To configure the Port Forwarding via CLI: config firewall vip     edit "Test"         set extip 20.20.20.20         set mappedip "192.168.3.3"         set extintf "any"         set portforward enable         set extport 11111         set mappedport 3389     next end To verify traffic hitting and using the correct policy, the following debugs can be used: Packet Sniffer: diagnose sniffer packet any ' host a.a.a.a and port bb ' 4 0 l <----- a.a.a.a is the source IP and port bb is the NAT port. Debug Flow: diagnose debug disable diagnose debug flow trace stop diagnose debug flow filter clear diagnose debug reset diagnose debug flow filter addr x.x.x.x   <----- x.x.x.x is the source IP. diagnose deb fl sh ip en diagnose debug flow show function-name enable diagnose debug console timestamp enable diagnose debug flow trace start 999 diagnose debug enable To stop the debug: diagnose debug disable Security Best Practices: Always restrict the source address in the VIP policy if access should only come from certain networks.  Do not use 'all' in source addresses for public-facing services unless necessary. VIPs do not automatically secure traffic. Firewall policies, UTM profiles (IPS, AV, SSL inspection) must be used if exposing sensitive services. Note: There was a change made to the behavior of the IP Pool and VIP after upgrading FortiOS to v6.4, v7.0, v7.2, and v7.4. For more information, see this article: Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4. Ensure that the service's external port and the FortiGate administrative access port are configured to use different ports. This helps avoid port conflicts and ensures secure and uninterrupted access to both services Related article: Technical Tip: Traffic not flowing via interface IP after configuring the VIP.