Virtual IP (VIP) outbound nat doesn' t work by default?

[Jeff_Roback]

The fortigate 5.x documentation states that when you create a virtual IP address (VIP) and do NOT specify port mapping, that traffic should be translated for both inbound (dnat) and outbound (snat) traffic. If says: " if you leave the ' port forwarding' checkbox unchecked it is therefore mapping all ports, it will do bi-directional NAting, so the single VIP entry will control both inbound and outbound address translation." Overall this seems like a very good thing for reducing the complexity of configuration for standard internet-accessible servers. However, we' re finding that this doesn' t seem to work unless you issue " set nat-source-vip enable" from the CLI for every VIP (it defaults to disable). By default, outbound traffic just falls through to the general nat pool that we have set up for all other clients. Is this the expected behavior? If so, I can' t see how the reference manual is correct. If this is needed, is there a way to change the default for all VIP' s to nat-source-vip enable? Otherwise it' s kind of a bummer to follow up each GUI based VIP with a cli command. Here' s an example of what I see from debug in each case. .163 is the shared pool setup for all clients, .184 is the VIP for this host. Note that the system sees the VIP outbound IP in both cases but just seems to ignore it by default. Outbound initiated traffic with default settings: id=20085 trace_id=2 func=resolve_ip_tuple_fast line=4310 msg=" vd-root received a packet(proto=6, 10.XX.XX.31:56200->64.XX.XX.216:80) from lan." id=20085 trace_id=1 func=get_new_addr line=2593 msg=" find SNAT: IP-206.XX.XX.163(from IPPOOL), port-56199" id=20085 trace_id=1 func=get_new_addr line=2593 msg=" find SNAT: IP-206.XX.XX.184(from IPPOOL), port-0(fixed port)" id=20085 trace_id=1 func=__ip_session_run_tuple line=2471 msg=" SNAT 10.XX.XX.31->206.XX.XX.163:56199" Here' s what I see after adding nat-source-vip enable: id=20085 trace_id=173 func=resolve_ip_tuple_fast line=4310 msg=" vd-root received a packet(proto=6, 10.XX.XX.31:57646->64.XX.XX.216:80) from lan." id=20085 trace_id=173 func=get_new_addr line=2593 msg=" find SNAT: IP-206.XX.XX.163(from IPPOOL), port-57646" id=20085 trace_id=173 func=get_new_addr line=2593 msg=" find SNAT: IP-206.XX.XX.184(from IPPOOL), port-0(fixed port)" id=20085 trace_id=173 func=__ip_session_run_tuple line=2471 msg=" SNAT 10.XX.XX.31->206.XX.XX.184:57646"

[MBR]

Hi Jeff, I ran into the same issue. I solved this by creating a specific outbound policy for the server behind the VIP and just enabled NAT on it. The FGT will use the VIP address for outbound traffic. I just had to make sure this policy is above a generic outbound policy which uses an IPPOOL because otherwise it would use the IP from the pool. But the solution to use the ' nat-source-vip' setting is better. We migrated over from Juniper ScreenOS based firewalls in which VIPs are automatically bi-directional. i hope Fortinet would add this setting to the GUI some day. Thanks for sharing.

[Christopher_McMullan]

Would someone volunteer to open a ticket to request this as a New Feature Request? With major releases containing new features, and patches reserved for bugs, this could make it to 5.4 if there is a strong enough push for it.

[VicAndr]

I " arrived" to this topic from another one where I had overlapping questions (thank you, ede ). To Jeff Roback: Thank you for bringing this subject to our attention! I' ve been using outbound firewall policies combined with IP pools to define servers' public IP addresses for outgoing traffic for years but didn' t know that there was a simpler and " cleaner" alternative to achieve reverse (source) IP NAT-ting through the very same VIPs. And reading through the posts I realized that I am far from being alone in this. By default it is disabled but could be enabled for a particular VIP with a single " set nat-source-vip enable" CLI statement. I don' t think that a VIP source NAT should be enabled by default - for majority of your publicly available servers you do not really need it. But it is great to know that you could easily turn SNAT on for those servers which require that. I agree with you and others though that Fortinet' s documentation misrepresents default status of VIP SNAT. To Christopher McMullan_FTNT: There is no need " to open a ticket to request this as a New Feature Request" . VIP SNAT has been readily available in FortiOS at least from v3.0.X. Some of us simply overlooked and didn' t use that feature. It would be nice though if there was a global option to change the default status of VIP SNAT to make " everyone happy" : those who are OK with default SNAT disabled - would keep it that way, and those who want it otherwise were able to change it. To MBR:

i hope Fortinet would add this setting to the GUI some day.

Yes, it would be nice to have a checkbox in GUI to enable/disable SNAT when you configure a VIP. But again, CLI has so many configuration options for every single object (which is awesome!) so it becomes a real challenge for FortiOS developers - what to include and what not into GUI while keeping it functional, yet tidy and uncluttered. I love this TMX1' s quote from Features that you would like to see topic:

I would like to see less " Features" and more of fixing the existing bugs! OH and stop changing/renaming stuff around for no reason.

[peter_wickenberg]

Hi

Thanks for the explainations, the solution was very simple when I understood my misunderstanding that was the reason for this not working as expected.

By binding the VIP to the guest network interface it started to work just as expected without disturbing the traffic from the printer in the administrative network out to the outside, so now everything is working just peachy. 

Best regards

Peter