Newbie requesting assistance with a port forwarding situation.

[dsmith225]

Hello All,

I just bought and put a Fortigate 60e in place with the most current firmware (6.2.2, build 1010GA). I am getting stuck trying to get a port forward solution working for external access to a plex server inside the Fortigate which is only leading me to banging my head against the desk. While I have been doing plenty of google searching and looking at the Fortinet cookbooks online which are great resources. I am wondering if anyone is willing to assist with breaking it down in layman's terms on how to set up the port forwarding. 

Thank you for any and all assistance!

-Dan

[ede_pfau]

Sure,

welcome to the forums.

Say you want to forward traffic to public WAN address 1.1.1.1 to your internal server at 192.168.14.1. So this is a destination NAT.

The object you need to create is called "Virtual address" or VIP in FortiOS.

Policy & Object > Virtual Address

create new, then enter

external address: 1.1.1.1

mapped-to address: 192.168.14.1

no port forwarding (at this moment)

To bring a VIP into effect, you use it in an inbound policy:

new policy,

source interface: wan

dest interface: internalX

source address: all (you don't know in advance)

dest address: <your new VIP>  !!

service: whatever applies

schedule: always

NAT: nope

and then test it.

Regarding port forwarding:

sometimes, esp. when you plan to allow several services into your LAN/DMZ, you make the VIP a port-forwarding VIP. The port specified should match the (custom) service you specify in the policy.

One caveat: you cannot test a port-forwarding VIP with ping. As ping is neither TCP nor UDP, and doesn't use ports.

The trivial VIP shown above can of course be tested by pinging your WAN address.

And while you do that, you notice why you might need port forwarding. SSL-VPN or IPsec VPN towards your FGT will send traffic to your WAN address as well - which will be forwarded completely to your internal server if you don't port-forward.

I wonder if VIPs (and the other form of NAT, source NAT) is not dealt with in the FortiOS Handbook. You need to have it around until you get the hang to it.

Feel free to post more questions if the need arises.

[TecnetRuss]

What I'd recommend is:

[ol]

If you only need a single port forwarded (e.g. 443), or a range of consecutive ports (e.g. 8080-8099), that are of the same single protocol type (e.g. TCP or UDP both not both) to an internal server, set up a Virtual IP with Port Forwarding enabled for that port (or range of ports) and protocol, then use that VIP as the destination in a WAN to LAN IPv4 policy.  You can set the Service on that policy to be the matching service for that port (e.g. HTTPS) or ALL if desired.  This is also the required method if you need to alter the port number in transit (e.g. forward TCP 9443 to TCP 443).

If you need to forward multiple ports (e.g. 53, 80 and 443) and/or multiple protocols (e.g. UDP and TCP), set up a Virtual IP without Port Forwarding and instead enable the "Optional Filters" and set the Services filter to your desired services (e.g. DNS, HTTP, HTTPS), then use that VIP as the destination in a WAN to LAN IPv4 policy.  You can set the policy's Service to the same services as you used in your VIP or leave it at ALL if desired.  This is cleaner than the alternative of creating multiple VIPs (method 1 above) and setting them as destinations in a single policy or multiple policies.

If you plan to create separate IPv4 policies for each port/protocol, i.e. if you need to apply different Security Profiles to different IPv4 policies for different ports/protocols/services then create separate VIPs as needed.

If you need to forward all ports and protocols to an internal server (1:1 NAT) then just create a VIP with no forwarding or "optional filtering" and use that as the destination of your WAN to LAN IPv4 policy.[/ol]

Correct me if I'm wrong but I remember reading somewhere that by filtering out unneeded packets at the VIP level (or IPv4 Access Control List) rather than relying solely on the IPv4 Policy's service filter that the switch controller's packet filter is saving the FortiGate from wasting unnecessary CPU cycles filtering it out during policy inspection.

Russ

[dsmith225]

We were able to get it working as needed with both of your help on this!  Thank you again!!