Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Jeff_Roback
Contributor

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

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"

Jeff Roback

Jeff Roback
1 Solution
ede_pfau
Esteemed Contributor III

Having reread the manuals I think that the feature is working properly but your expectations differ from the implementation. In your example, 10.x.x.31 is mapped/not mapped to the VIPs external address 206.x.x.184. The critical information lacking here is the value of the internal (" mapped to" ) address. I bet it is NOT 10.x.x.31. The reverse mapping feature of VIPs is meant to cover the mapped-to address ONLY. Imagine a DMZ with one server to be accessible by public IP address, and other hosts in the DMZ for which no VIPs exist. Then, using the defaults, traffic from the server would be source NATted to the " mapped-to" address in the VIP but other traffic would not, using the interface IP or an IP pool instead. Otherwise, traffic from all hosts would seem to come from the one server that is made public by a VIP. This would rather be surprising. The main disadvantage of having a VIP cover all source addresses of its interface automatically would be that you cannot undo this NAT. If you intend to differentiate between traffic from the public server and that of other hosts you would not be able to deselect such a source NAT. So, in short: hosts explicitely specified in a VIP are automatically source NATted by the VIP. Other traffic is not NATted unless you configure source NAT via IP pool.

Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
13 REPLIES 13
MBR
New Contributor III

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.

- MBR -

NSE1, NSE2, NSE3

FGT60D/E, FWF60D/E, FGT200D

- MBR - NSE1, NSE2, NSE3 FGT60D/E, FWF60D/E, FGT200D
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.

Regards, Chris McMullan Fortinet Ottawa

VicAndr
New Contributor III

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

Labels
Top Kudoed Authors