Port Forwarding &Port Address Translation

[ttreat]

Hello all,

We have a Fortigate 100D. I am setting up some port forward & port address translation rules. In looking at the documentation in the KB and the cookbook, I see some differences to the recommendations:

* KB article:  http://kb.fortinet.com/kb/documentLink.do?externalID=12945 

* Cookbook article: http://cookbook.fortinet.com/using-virtual-ips-configure-port-forwarding-54/ 

They basically recommend the same process of 1) Create VIP 2) Create Firewall Policy to allow traffic to VIP.

The cookbook says to create the policy and limit the services allowed to only the ports/services needed by the VIP, however the KB articles says when creating the policy that it is not necessary to specify a service to allow, and that it can be left to "ANY" since the VIP (with Port Address Translation turned on) only forwards packets using the specified port. 

So my questions are this: 

1) Is this ok to leave as the "Action=Accept" for "Service=All" for the policy if the "Destination=VIP"? Would the logs still show traffic getting dropped if someone tries to access the public IP on a port that is not getting forwarded via the VIP? 

2) If so, why wouldn't I just create one policy/rule that allows access to All services with the destination defined as all my VIPS and/or ViP Groups? Why go through the hassle of creating custom services (since I have one public IP accepting same service on behalf of multiple internal machines) and putting them into the rule? The custom services seem redundant in that they ask for source and destination ports to be defined again. The only reason I can think is that maybe the logs wouldn't show the traffic dropping for ports outside the defined range. I also want to be extra sure the VIP is not allowing any traffic on the ports not defined/forwarded as part of the VIP. 

Hope this was clear.  Thanks for any clarification on best practices around VIPs and Port Forwarding. 

-Tom

[boneyard · Accepted solution]

if you indeed only use VIPs with specific port forwards then you could go with the service ANY approach. if you have one VIP that forwards all ports then you probably don't want to go with that approach.

as for logging deny traffic on VIPs that is a bit more complicated then expected perhaps, read these KBs

http://kb.fortinet.com/kb/documentLink.do?externalID=13901

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36750 

the FortiGate offers multiple options, there often isn't one the best for everyone and quite often documentation just doesn't go that far to consider all options.

[boneyard · Accepted solution]

if you indeed only use VIPs with specific port forwards then you could go with the service ANY approach. if you have one VIP that forwards all ports then you probably don't want to go with that approach.

as for logging deny traffic on VIPs that is a bit more complicated then expected perhaps, read these KBs

http://kb.fortinet.com/kb/documentLink.do?externalID=13901

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36750 

the FortiGate offers multiple options, there often isn't one the best for everyone and quite often documentation just doesn't go that far to consider all options.

[rwpatterson · Accepted solution]

With my policies, I like to use the 'Count' option in the GUI to get a quick visual snapshot of what policies are being used and what can possibly get chucked. If you group all of your VIPs into a single policy, you lose that ability. Also troubleshooting is easier if the policy pertains to traffic of a single destination as opposed to several. Functionally though, they do the same thing.

My two cents.

[vjoshi_FTNT]

1) Is this ok to leave as the "Action=Accept" for "Service=All" for the policy if the "Destination=VIP"? Would the logs still show traffic getting dropped if someone tries to access the public IP on a port that is not getting forwarded via the VIP? 

Yes, the KB articles provided earlier should do

2)  If you have multiple virtual IPs that are likely to be associated to common firewall policies rather than add them individually to each of the policies you can add the instead. That way, if the members of the group change then any changes made to the group will propagate to all of the polices using that group.When using a Virtual IP address group the firewall policy will take into account all of the configured parameters of the Virtual IPs: IP addresses, Ports and port types.