Virtual IP inbound NAT using wrong IP going outbound

Thanks micahawitt. Yes you understood what I was trying to say. I don' t normally use IP pools when choosing NAT on an outbound policy, normally I leave it set to use destination interface address. I did actually have a firewall policy like you described set (but using destination interface address on the NAT setting) but it was preventing some machines on the LAN accessing the internet that was revealed when I did a packet trace from the CLI. It probably relates to the fact this thing has 8 routes out to the internet and port 9 is the first entry in the static routing table, hmmm.

well... if you move the policy higher up in the list for your single outbound nat with ip pool, your routing table shouldnt affect to much for your default clients. Anything default for clients, make sure it is that last one possible.

I did try to move the policy up but it refused because I am using a zone to group some interface mode IPsec tunnels together. It comes up with this: " Moving a policy from one interface/zone pair to a different interface/zone pair is not permitted." If I wanted to move it up would I have to take out the IPsec tunnels in the zone that are terminated on the port that relates to the policy that I am trying to move?

Thanks again but I do have the ID column shown, I remember going from the older green interface to the new look and wondered where the ID had gone to :) Perhaps if I try to shuffle the VPN zone around it might then let me move the firewall policies that relate to outbound internet access?

if you are within a zone, say port12 to wan1, then you should be able to shuffle them around. If not, then i would leave tunnels as they are, then you would probably have to delete the non tunnels, and recreate them as needed. it really depends on how it is setup and the overall goal. Sometimes i have put myself in a pickle with that and realized i had to recreate all my policies becuase of poor planning on my part on how i wanted things to flow. as i think about this a little more clearly, the only thing that should change is the fact that you added an ip pool to your one policy. as long as your default outgoing port, port9 it sounds like houses all your external ips, then you should be ok. the move the id up one from the default outgoing and add the ippool outbound nat. otherwise, delete that one policy, recreate it on port12 to wan1, set the outbound ip pool and should be good to go. then all the other policies can stay as is.

It' s looking like I might have to re-create some policies on this thing to try to get it to behave how I need it to. I inherited this config (I converted the config from a 200A to this 200B) and its not ideal now so I might try to shape the interface that it uses for internet traffic using priorities on the static routes out to the internet. Thanks for your advice :)

NPS!! Good luck!!

My understanding is that if I NAT something inbound then it should use the same external IP on the VIP to go outbound?

This is an incorrect preconception. What interface and what IP your server has for flows (sessions) it initiates itself is controlled by the routeing/routing table. The IP you present, per interface is most dominantly impacted by whether the Virtual-IP you' ve configured is shared (by specifying ports or port ranges) or dedicated (1:1 NAT). IP Pools can give you a certain internet identity but this isn' t an ideal configuration if you mention your Virtual-IP in your Virtual-IP-Pool. If you want your inbound VIP to be used to present your public IP identity on outbound streams then configuring your VIP as a 1:1 NAT is best. Then simply don' t allow Internet->DMZ connectivity beyond what you want to expose for inbound flows from the general public. Of course you' ll burn more public IPs this way but you may regret trying to mix SNAT (outbound flows using a pool) with DNAT (inbound flows using VirtualIP) where the public IP is the same address. In FortiOS it seems consistently bad practice to try this. Static routes (be they enhanced or not by the features of ECMP with its optional biasing (weighting, spillover) and PBR) dictate whether you' ll initiate a flow from your server over one line or another. It would be nice if PBR was another bias option that could have multiple entries to steer the ECMP/load-balance engine but adding features like this would probably take some convincing for the Fortinet engineers. Most routeing/forwarding features we have here seem to be present only when they also have some representation in Linux/BSD or Windows in order to appear in FortiOS. There are some exceptions where commercial load balancer philosophies/paradigms have been made equivalent in FortiOS and implemented quite well. Nevertheless, configuration of forwarding to the utmost extremes of flexibility isn' t where these platforms are at currently. For example, being able to control how the forwarding cache ages out isn' t in the current bag of tools.