Virtual IP inbound NAT using wrong IP going outbound

[ChEd]

Hello All, Following a thread I posted recently related to routing the same firewall is giving me problems with a NAT (fortigate 200B, running v4.0,build0639,120906 (MR3 Patch 10)) I am struggling to find a reason why a server with inbound NAT configured using a VIP (for email to flow inbound) is not going out on the same interface it came in on. My understanding is that if I NAT something inbound then it should use the same external IP on the VIP to go outbound? So if I have set it to use a specific external IP coming inbound on port 12 it should show that IP as its IP if it makes an outbound connection? The email server makes outbound connections to mimecast for sending mail and its locked to a specific IP. I have seen this work fine on other fortigates but this one is showing it as using port 9 going out which shouldn' t happen with a server running on a VIP right? The weird thing is its still accepting connections inbound for RDP/email etc. just fine but I had to use a policy route to force it to use the correct interface to go out to mimecast and when I do this the IP when you telnet the mimecast servers is the correct one that I have set as the external IP on the VIP. Here is the setup: port12 -> internal - this has the VIP on it but when the server goes outbound its using port 9?! The firewall in question does have multiple routes out to the internet but I am getting reports that the internet speed is not great for users but its just doing source IP based ECMP so perhaps its just hitting port 9 a lot since this is the first route to the internet in its routing table?

[Richard_Bartlett]

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.