1:1 static NAT that only affects traffic from one interface?

[ispcolohost]

When adding a Virtual IP mapping, i.e. 1:1 NAT, the Fortigate has an Interface box, which you'd think would actually perform some role, such as isolating the NAT to the interface in question.  In reality, adding a Virtual IP seems to affect traffic to the IP in question across all interfaces, regardless of the interface setting.

We have a situation where traffic traversing a Fortigate through a large number of interfaces should flow exactly as the rules allow, and no virtual IP's are involved.  The same Fortigate has dial-up ipsec VPN users, and for them specifically, we need them to have traffic intended for a public-facing IP get remapped to a private IP out a different interface, because DNS points everything to the public IP.  I added a Virtual IP with the mapping in question of public to private, and set the interface to be the VPN interface, but that immediately broke all other traffic traversing the firewall to the public IP because it began trying to rewrite everything.

Is there a workaround for this?  and what's the point of the Virtual IP rule interface box since it seems to cause the same problem whether set to an interface or set to Any?

[lobstercreed]

There isn't much function to the interface box in the GUI.  I would say it serves roughly the same purpose as the same box for a regular firewall address definition.  The address/VIP doesn't appear as an option unless you select that interface, so it could be helpful in avoiding mistakes/reducing clutter in the GUI.

Having said that, what you want I think does exist (I've never used it) in the CLI but it is called srcintf-filter:

https://docs.fortinet.com/document/fortigate/6.4.5/cli-reference/293620/config-firewall-vip  Let me know if that works.  I've never needed it, but I could see it being useful for me in a couple scenarios down the road.

[ispcolohost]

Thanks for the tip.  I just tried; it didn't work, still broke all traffic through the Fortigate when in place.

[ispcolohost]

I'm going to see if the DNS translation stuff works interface-specific or breaks everything too :)

[Toshi_Esumi]

I still don't understand what you're trying to do. You were saying that you set a VIP from the public-facing IP (say x.x.x.x) to a private IP, which inside of your network. But, isn't that x.x.x.x the IP those dial-up VPNs are connecting to? Which would never come through the tunnel from the client side. Always comes outside of the tunnel over the internet and hit the physical (maybe a vlan) interface that has x.x.x.x.

[ispcolohost]

toshiesumi wrote:

I still don't understand what you're trying to do. You were saying that you set a VIP from the public-facing IP (say x.x.x.x) to a private IP, which inside of your network. But, isn't that x.x.x.x the IP those dial-up VPNs are connecting to? Which would never come through the tunnel from the client side. Always comes outside of the tunnel over the internet and hit the physical (maybe a vlan) interface that has x.x.x.x.

This particular firewall cluster has traffic arriving from several interfaces servicing different physical locations and/or department VLANs, all of which have users who interact with what we'll say is public IP 192.0.2.100 that lives on a DMZ VLAN and is a web app firewall software appliance.  If the traffic is allowed through the WAF, it is proxied to the real application server that lives on an internal VLAN interface with private IP 10.0.0.100.

So, all the rules allow traffic from all these random interfaces through to 192.0.2.100, no problem.

The same firewall is the termination point for client to site IPSec FortiClient VPN users, and for that user population specifically, we do not want them talking to the WAF, I want to 1:1 map their traffic to 10.0.0.100 even if they were trying to get to the 192.0.2.100, so they don't have to deal with hosts files, custom DNS overrides on their side, etc.  I was thinking a VIP to do that mapping, that only applies to the VPN interface, would solve the problem, but it instead broke all traffic.  lobstercreed's reply pointing out srcintf-filter sounded like the entire purpose of that command was to solve this problem, where the VIP mapping would only affect traffic from the one single interface, but even with that in place the VIP config still broke all the traffic.  So even if you restrict a VIP, it appears to affect traffic from all interfaces either way.

[ispcolohost]

Nope; I have a feeling that only works if using the Fortigate itself as the DNS server or proxy... ugh.  I've done rules-based 1:1 NAT on a pfsense before, super easy, but apparently this isn't an easy problem to solve with Fortigate.  It's pretty weird an interface-specific VIP has the ability to attempt to alter all traffic traversing a box.

Guess we'll try to deal with the issue downstream of the Fortigate with the users in question.