I ran into the following problem when configuring a Fortigate Firewall.

I created a general purpose internet rule on the Fortigate. Which looks like this:

Internal networks – to – Internet // protocols : tcp/80/443

Like in most cases I enabled NAT on the security policy. With the option to use the address of the ‘outgoing interface’. This worked fine of course.

But, here comes the but :

I created a VIP (destination NAT) for a specific server (server A) which needed to be reachable through a VPN tunnel.
So I created a VIP for server A to be reachable at an address known in de VPN configuration. (VIP: NAT_address_srvA – real_address_srvA – type: ONE-to-ONE static)
Added this VIP to a security policy in the destination field.

vpn – to – internal networks // protocols : tcp/80/443

After adding this last rule, server A was not able to reach the internet anymore.

In the debug logging we saw that for internet traffic from server A not de ‘outgoing interface of the internet interface was used’ but the NAT address we defined in the VIP.
Because static VIP (one-to-one) works bi-directional.

As Fortinet describes this behavior:
Virtual IPs (VIPs) are destination NAT objects. For sessions matching a VIP, the destination address is translated: usually a public Internet address is translated to a server’s private network address.
VIPs are selected in the firewall policy’s Destination Address field.
The default VIP type is static NAT. This is a one-to-one mapping, which applies for incoming and outgoing connections. That is, an outgoing policy with NAT enabled would use the VIP address instead of the egress interface address.
This behavior, however, can be overridden by use of an IP pool.

So I resolved this problem by not using the “outgoing interface” as NAT type. But by using an ippool.

In my opnion this also a best practice for adding a ‘general purpose’ internet rules to a Fortigate. To use a ippool instead of the outgoing interface address to NAT traffic over. (Just a tip)