Using virtual IPs to configure port forwarding

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

This recipe demonstrates how to use Virtual IPs (VIPs) to configure port forwarding on a FortiGate unit. This configuration allows users on the Internet to connect to your server protected behind a FortiGate firewall, without knowing the server’s internal IP address and only through ports that you choose.

In this example, TCP ports 80 (HTTP), 21 (FTP), and 22 (SSH) are opened for remote users to communicate with a server behind the firewall. The external IP address used is 172.20.121.67 and is mapped to 192.168.100.1 by the VIP.

Find this recipe for other FortiOS versions:
5.2 | 5.4

1. Creating three VIPs

Go to Policy & Objects > Virtual IPs > Create New > Virtual IP.

Enter the External IP Address/Range. Next, enter the Mapped IP Address/Range.

Enable Port Forwarding and add a VIP for TCP port 80, webserver-http.

 

Next, create a second VIP for TCP port 21, webserver-ftp.

Finally, create a third a VIP for TCP port 22, webserver-ssh.

2. Adding VIPs to a VIP group

Go to Policy & Objects > Virtual IPs > Create New > Virtual IP Group.

Create a VIP group, in this example, webserver group. Under Members, include all three VIPs previously created.

 

3. Creating a security policy

Go to Policy & Objects > IPv4 Policy and create a security policy allowing access to a server behind the firewall.

Set Incoming Interface to your Internet-facing interface, Outgoing Interface to the interface connected to the server, and Destination Address to the VIP group (webserver group). Set Service to allow HTTP, FTP, and SSH traffic.

Use the appropriate Security Profiles to protect the servers.

 

4. Results

To ensure that TCP port 80 is open, connect to the web server from a remote connection on the other side of the firewall.

 

Next, ensure that TCP port 21 is open by using an FTP client to connect to the FTP server from a remote connection on the other side of the firewall.

Finally, ensure that TCP port 22 is open by connecting to the SSH server from a remote connection on the other side of the firewall.

 

For further reading, check out Virtual IPs in the FortiOS 5.4 Handbook.

Judith Haney

Judith Haney

Technical Writer at Fortinet
Judith Haney is a Technical Writer on the FortiOS technical documentation team. She graduated with honours from Algonquin College's Technical Writer program in September 2014. In a previous lifetime, Judith earned degrees in Mathematics (B.S.) and French literature (M.A.).
Judith Haney
  • Was this helpful?
  • Yes   No
While this example maps port 80 to port 80, any valid External Service port can be mapped to any listening port on the destination computer.
If the FortiGate has Central NAT enabled, the VIP objects will not be available for selection in the policy editing window.
  • Marcin Biłek

    I would like to ask a similar thing as in the subject. I have a linux server on the network and would like to be able to see from what public addresses were trying to log in to SSH on port 22. All these addresses are present in the address of the router and I am interested in seeing the real addresses how can this be done?

  • Leo Edwardsson

    How do I add a new VIP to a pre-existing VIP Group? I don’t want to make a new group, but the edit page for the existing group only gives me the option to delete VIPs from the group, not add new ones.

    • Victoria Martin

      Hi Leo,

      I tested this out on a FortiGate here running 5.4 and was able to add a new VIP to an existing VIP group; however, I did notice that the usual plus button did not appear at the bottom of the list of VIPs in the group, which does make it look like you can only delete group members rather than add new ones. If you select the box showing the members, you will be able to add a new VIP to the group.

      I hope that helps!

  • sasikumar

    hi i am having a situation that i need to port forward particular port number with particular static IP (which is outside network) to my server network. (Eg: Port Number is 443 and the outside IP is 185.151.161.18) this ip and my server network should use this 443 port as a tunnel. anyone can help me in this

  • Andres Altamirano

    I’ve created a VIP object, but can’t add it as a destination in a Firewall Policy, just addresses and groups are available. Is there something I miss to do before?

    • Victoria Martin

      Hi Andres,

      Doublecheck that you have set the VIP to use the correct interface. The interface must either be the ANY interface, or it must match the Incoming Interface in your policy.

      If you have the correct interface, I would recommend contacting Fortinet Support: http://cookbook.fortinet.com/how-to-work-with-fortinet-support/

  • jonathan gohstand

    The example assumes a static public IP address. What if the ISP connection is using a dynamic address and DDNS? How would the VIP be configured?

    • Victoria Martin

      For that scenario, create the virtual IPs as follows:

      External Interface: WAN
      External IP Address/Range: 0.0.0.0
      Mapped IP Address/Range: X.X.X.X
      External Service Port: 85
      Map to Port: 85

      By setting the external IP to 0.0.0.0 would allow the VIP to work with a dynamic IP.

      • claudio arriagada

        Hi, in this configuration, have I to kept the NAT enable at the policy configuration?

  • Alexander Tatevyan

    On your security policy screenshot, the NAT is depicted as enabled, which may cause problems in case of incoming DNS queries from external users to a VIP address of the internal DNS server. In fact, most internal DNS systems keep two zones; one for internal, and the other – for external queries, and, depending on the source address of the query, the DNS may resolve to a public or a private address of the same internal server, for example, a web server. Now, when you enable NAT on an incoming security policy, you’re effectively translating external source IP to a private IP of the outgoing interface, and this causes a real problem, since DNS will see a query as sourced from an internal IP, and return the private (internal) address of the resource, instead of the external (public) one. The VIP mapping is already performing the destination address translation, there’s no need for the source address translation, at least for DNS service. I had this very problem with my setup; first I followed this article to write the policy, and ran into the above mentioned problem. By disabling NAT in the policy, I managed to fix this issue.

    • bdickie

      Thank you very much for your detailed comment. You are of course correct and we will fix the recipe.

  • Alexander Tatevyan

    So, in case of dual wan scenario, I need to configure one more set of Virtual IPs pointing to the same internal resources, but with VIPs bound to the second wan port. Right?

  • montstrid

    hi, is there anything special to do when you have 2 WANs working and what you want to publish is using the second WAN, ??? like static route or something ??? and speaking of WAN2 the connection there is made as a bridge using a dynamic public IP. Thank you in advance.

    • Kerrie Newton

      Hello,

      To give WAN2 preference you will have to configure distance for WAN2 to be a smaller number than WAN1. Note: if you have any policy route configured, that will take the preference.

      Regards,
      Kerrie

      • Jorge

        Thanks, what about priority?

  • StopTheOrangeCancer

    great

  • Ferryanto Pakpahan

    its not work for me…the page going to fortigate login page…

  • Gilberto

    Thanks!!!