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"

[Istvan_Takacs_FTNT]

do you have 2 different policies for all clients and another one only for 10xxx31? I guess " all clients" use either the Fortigate external interface to getting NATed outbound or you specified a NAT address, xx.163? The 10.xx.31 host should have a policy that NATs outbound traffic to a /32 ippool objects in the policy to 206.xxx.184. VIP is for inbound NAT. IPPOOL is for outbound NAT. If you want to provide external access to your internal host, you use a VIP. You need to use the VIP in the " Destination address" field. If you want to provide outbound access to your internal host, you enable NAT and either use the firewall external interface, or you specify an ippool address object that FGT will use to NAT it to. Not sure about ' nat-source-vip' , but you don' t have to change the default, unless you want prevent unintended servers from using the VIP. Here' s an example: FGT external interface IP: 172.16.233.10 FGT external port: port1 FGT DMZ port: port2 internal web server IP: 192.168.10.10 internal web server public IP: 172.16.233.12 INBOUND: # show firewall policy config firewall policy edit 3 set srcintf " port1" set dstintf " port2" set srcaddr " all" set dstaddr " webserver-vip-443" set action accept set schedule " always" set service " HTTPS" set logtraffic all next end OUTBOUND config firewall policy edit 3 set srcintf " port2" set dstintf " port1" set srcaddr " webserver-internal" set dstaddr " all" set action accept set schedule " always" set service " SSH" set logtraffic all set nat enable set ippool enable set poolname " webserver-ext-ippool" next end # show firewall ippool config firewall ippool edit " webserver-ext-ippool" set type fixed-port-range set startip 172.16.233.12 set endip 172.16.233.12 set source-startip 192.168.10.10 set source-endip 192.168.10.10 next end # show firewall vip config firewall vip edit " webserver-vip-443" set extip 172.16.233.12 set extintf " port1" set portforward enable set mappedip 192.168.10.10 set extport 443 set mappedport 8543 next

[ede_pfau · Accepted solution]

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.

[Jeff_Roback]

Thanks for take a look at this guys. @ede_pfau Re : " 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." Actually that is exactly what I' m doing. Here' s the configuration. config firewall vip edit " Test Server" set extip 206.XX.XX.184 set extintf " wan1" set nat-source-vip enable set mappedip " 10.5.XX.31-10.5.XX.31" next End edit " WAN1 Globl PAT Address IPP" set startip 206.XX.XX.163 set endip 206.XX.XX.163 next edit 37 set srcintf " lan" set dstintf " wan1" set srcaddr " all" set dstaddr " all" set action accept set schedule " always" set service " ALL" set logtraffic all set nat enable set ippool enable set poolname " WAN1 Globl PAT Address IPP" next end " So, in short: hosts explicitly specified in a VIP are automatically source NATted by the VIP. Other traffic is not NATted unless you configure source NAT via IP pool. " Yes, this is exactly what I' m trying to accomplish: I want to have internet facing servers to each have a single public ip for inbound and outbound traffic. Then I want to have all other devices (User worksatations, non public facing servers, etc) use a common NAT address that isn' t the same as the firewall interface IP (It' s an old habit, but having the interface IP used for outbound PAT always seems to cause problems with IPSEC tunnels). So based upon the documentation, it seems like I can do this with just the VIP, which saves the additional configuration of creating an IPP and a policy and keeping all of that in sync. The configuration above works perfectly once I add in the " Set nat-source-vip enable" , but in the default configuration with " Set nat-source-vip disable" it doesn' t. So it seems like either the documentation is wrong, or there' s a bug in the feature. Ultimately if there was a way to set " Nat-Source-vip enable" to the default on all VIP' s I' d be happy :-) @ Istvan Takacs I am aware of the option of using VIP for inbound nat and IPPOOL for outbound nat. But in reading through the documentation it occurred to me that if I' m planning on using the same IP for inbound and outboud nat, it would be much cleaner to have just a single VIP for the server instead of having to create an IPPOOL and a policy separately for each inbound server… cuts the config a lot. Plus it' s less objects to keep track of and keep in sync as things change over time. Thanks!

[ede_pfau]

You' re totally right. With this previously missing piece of information I would call that a bug in the VIP implementation. Rather, the effect of " nat-source-vip" is reversed, the default as " disabled" seems OK. If you care enough please open a ticket with TAC to have this verified and if so, corrected in a future bug fix. And good to know, thanks for posting your problem. This should affect other as well who might be wondering what is going on with these VIPs...

[Jeff_Roback]

@ede_pfau Thanks for confirming my thoughts on this. I did originally open up a case with TAC and they insisted that it doesn' t work this way and I should just use a Pool for outbound.... but I think the person that added this feature sure intended for it to work this way :-) Even the examples in the documentation for video conferencing, for example, are going to break if you follow the directions because without nat-source-vip the outbound traffic won' t nat to the same ip as inbound. @netmin yes there is an inbound policy that allows the traffic in (I just left that out to keep the configs small. Always a tough choice what to include or exclude.) I think the thing that confirms this is all setup correctly is the nat-source-vip behavior. Without any additional changes, when in the default state, the outbound traffic uses the shared Ip address. once I change nat-source-vip, it immediately changes outbound traffic to begin using the VIP address. This is one of several FGT' s were just bringing live. We' re in the process of transitioning from sonicwalls at several customer sites. So far I' m really loving the fortigates, and I' m trying to develop overall best practices for our team going forward.

[netmin]

Are you using any inbound allow/deny policy to your VIPs? The KB article http://kb.fortinet.com/kb/viewContent.do?externalId=FD31893 mentions that for pure outbound 1:1 NAT an inbound policy is required to activate it or the interface IP is used (or likely the ippool as in your case).

[ede_pfau]

Thanks for the hint. The article confirms that reverse (source) NAT to the VIP' s external IP address is done automatically, as long as the VIP is activated as a destination address object. The real usefulness of this 1:1 NAT would be more obvious if the VIPs were not consecutive in a range. Frankly, the more I read that is should " just work" the more I think it' s a bug.

[Jeff_Roback]

So I opened up a case w/ support and after they looked at it they said " Oh, you' re using a IPP on the interface. It won' t work then. Once you use one IPP then bidirectional VIP' s don' t work. Which again strikes me as a bug or a documentation error. So it seems to me that they should really update the documentation to tell you that VIP' s only work bidirectionally if set nat-source-vip enable is put in. Or ideally they' d set the default state of set nat-source-vip to enable for new VIP' s and/or expose that flag in the GUI. This is a really great feature that can dramatically simply common configurations, so I' ve got to think the team that put it there intended for it to be used this way, which is why it' s covered so clearly in the documentation and KB.... But I' m not sure I can get tech support to take it much further :-( Jeff

[netmin]

I only got the impression that Jeffs FGT is just being set up (or planned) and the VIPs might not yet have an inbound policy associated with them.