Virtual IP's with source exclusion instead of inclusion? Or alternative...

[ispcolohost]

Hi all, I have the following scenario:

Data Center (fortigate 200D):

internal web app at 192.0.2.1:443 no auth required

internal web app firewall at 192.0.2.2:443 which requires certificate auth and reverse proxies traffic to 192.0.2.1:443

FortiGate "Virtual IP" defined where public IP 1.2.3.4:443 maps to 192.0.2.2:443 (the web app firewall)

DNS for this web app points at the public virtual IP, not an internal IP

Office (fortigate 200D):

40+ subnets downstream of the fortigate routed to it over one VLAN port (Downstream, tagged port1) serving as the next hop router

2  wired networks to physical ports

1  wired network serving wifi access points for non-employees and employees personal devices (port4)

The goal is to have all employees who go to the domain name for the web app hit the app server directly at 192.0.2.1.  The reason DNS points at the public IP is because the employee subnets don't all share the same DNS servers, and overriding with the internal IP on all of them would be impossible.  Some employees even use public DNS servers like Google's, etc. so even if we could override on all the internal DNS systems, it would still not be complete.

So, on the office fortigate, I simply have:

config firewall vip

    edit "WebApp Internal Mapping"

    set extip 1.2.3.4

    set extintf "any"

    set mappedip "192.0.2.1"

  next

end

With this in place, problem almost solved.  All users who are remote and have a proper client cert installed type in the domain name for the app, hit the data center fortigate's virtual IP, access app no problem.  All users at the office, regardless of their DNS settings, also have traffic heading towards the public IP, and then the destination NAT occurs and their traffic instead traverses the VPN and hits the internal application server IP.

The problem is that one single wifi network at the office.  That network is guests, and employees' personal devices, I do not want it destination NAT'd.  A guest or personal device on the wifi network should go to the public IP just as they're trying to and certificate auth just like they were on the internet.

The problem is that 'extintf' set to any value other than any doesn't seem to work.  Even if I set it to a given interface and it did work, I can't add a second instance for another valid interface because it says "The virtual IP is overlapped with another VIP entry".  

Next idea, I found the srcintf-filter directive.  It does not appear to work as intended.  I kept my VIP the same and added:

config firewall vip

    edit "WebApp Internal Mapping"

    set extip 1.2.3.4

    set extintf "any"

    set srcintf-filter "Downstream" "port2" "port3"

    set mappedip "192.0.2.1"

  next

end

That did not change things.  It should have meant the destination NAT only occurs for traffic coming from those three ports, or so I thought, leaving the 'port4' wifi users unaffected.  Traffic from wifi users to 1.2.3.4 never makes it out of the fortigate; sniffing it at the fortigate level shows syn packets to the public IP, no translation, but not passing it either.  I'm guessing it's trying to still do the translation, finding that isn't permitted by rule, and dropping.

I have not yet tried the source address filter, and would prefer not to since I don't really want to have to manually define 40+ networks as allowed, and have to keep adding/removing as the downstream networks change.  If I have to I can but ugh.

Any chance of an opposite of the source address filter, where I can somehow tell the virtual IP definition to not act on one source IP range, or not act on one incoming interface? 

Would a VDOM be a workaround for this?  I could try putting the wifi port in its own VDOM, but then would have to make a virtual interface somewhere with the regular firewall interfaces as a next hop to let it get to internet.

[gnawsti]

Hi guys

I am new in fortigate and using it as gateway device in an enterprise environment. Changes will be perform under "config firewall vip". Is there an impact in production if any of below will be change?

config firewall vip     edit "WebApp Internal Mapping

----> set extip n.n.n.n  ---->set extintf "wan1"   ---->set srcintf-filter "Downstream" "port2" "port3"   ---->set mappedip "x.x.x.x"   next

Thank you in advance.

[ispcolohost]

As best I can tell, srcintf-filter does absolutely nothing.  If you define a VIP on a Fortigate, it's device (or VDOM)-wide, so even if you add a srcintf-filter, it will still affect the traffic coming from those interfaces.

[gnawsti]

@ispcolohost Thank you for the reply. If set mappedip x.x.x.x is an external ip (server on internet) and will be changed, upon change to y.y.y.y there will be a connection lost to server?

[ispcolohost]

Correct, I personally consider this a bug.  If you define a VIP x.x.x.x on a specific interface, then regardless of it not being set to 'any', and even if you set srcintf filter restrictions, all traffic destined to that IP will be affected even if it should have passed through the firewall un-touched via other interfaces where rules permitted it.