VIP not attached to ONE interface

[tiagomiranda]

Hello ! 

I `ve a strange behavior on Fortigate.

I have a VIP (10.1.1.1) attached to a Interface. This VIP IP is also a Valid IP (10.1.1.1) address on another DC (not a subnet directly connected to Fortigate).

My problem is that the VIP that is attached to the interface port3 for example, stop the Valid IP address from working on another Interfaces.

So, if i try to access the valid IP address (10.1.1.1) on ANOTHER interface, not the VIP Interface, i have a drop from fortigate.

If i defined a source-filter on the VIP from a subnet different that my (10.2.2.1) it works.

I already disable set arp-reply on the VIP.

In my conception the VIP only should respond and work on the Interface that is attached too.

Any tips to solve this behavior? 

I already has a ticket with support but still without response.

[Thoey]

Any luck with this?  I'm seeing the same thing where I have configured the VIP and srcintf-filter to be on one interface, however traffic coming in other interfaces are being processed by the VIP.

[ispcolohost]

I spent a few hours with two different support people on it where I did a gotomeeting session and they did debugging, but no resolution.  They were able to see in the policy flow debug that packets come in, the VIP applies when it shouldn't, and then they're dropped.  They were hesitant to call it a bug, suggesting that when a VIP is defined, that means the Fortigate owns that IP address and it *should* apply to all traffic passing through the device.  My response to that was well there's no purpose to even having a VIP support an interface definition and source interface filter if it's just going to apply to all interfaces and all sources anyway, given the policy still decides what happens to the traffic.  Going to see where that goes.

What I ended up having to do to work around this was really ugly.  I enabled virtual domains, created a new VDOM to perform the destination NAT that I needed to apply to only certain traffic, policy routed traffic to that VDOM as the next hop if the source is all of the networks I want the VIP to apply to, then static default route back that VDOM across the same inter-vdom link after having been destination NAT'd and let the traffic go where it was intended.  Now the networks I can't have affected can keep working and the rest get the destination NAT I was intending.  

[jhouvenaghel_FTNT]

Hello,

When you mention "A second interface that should not be subject to the destination NAT is affected too though, even though my extintf is set to the desired interface, and I added srcintf-filter specifying the desired interface too."  , could you give parts of the config showing the vip definition, your vip policy and any policy between your second interface and the external interface used by the VIP.

Thanks

[ispcolohost]

Sure; here's rough version:

We have an internal service at 10.0.1.1, but DNS points to a public IP 1.2.3.4.  We want all staff users passing through our office firewalls to be destination NAT'd to 10.0.1.1.  However, non-staff and staff personal devices that may be on the office wifi networks, which go through the same firewall, we want going to the public IP as they will have attempted.  So I added the following, and am also including the wifi rule:

config firewall vip   edit "NAT Internal Chat"     set extip 1.2.3.4     set extintf "Transit"     set srcintf-filter "Transit"     set mappedip "10.0.1.1"   next end

edit 174   set srcintf "Transit"   set dstintf "VLAN300"   set srcaddr "Staff-vlan300"   set dstaddr "NAT Internal Chat"   set action accept   set schedule "always"   set service "HTTPS" next

edit 10 set name "Wifi to Internet" set srcintf "port2" set dstintf "wan1" set srcaddr "Wifi-users" set dstaddr "all" set action accept set schedule "always" set service "ALL" set nat enable set ippool enable set poolname "Wifi External" next

Once I put that in place, all staff (traffic coming in from vlan interface "Transit") began to properly have their traffic for 1.2.3.4 rewritten to 10.0.1.1.  However, users on the wifi (downstream of port2 on fortigate) lost access to the public IP.  That's when I involved support since my thought was that if the VIP is defined with an extintf, and further restricted with srcintf-filter, then why would traffic on port2 be affected.  Their explanation was that defining a VIP at all makes the fortigate 'own' that IP internally so traffic traversing it at all would be affected.  That seems to make extintf and srcintf-filter pointless since the firewall behaves the same whether it's "any" or specific, and whether the filter is there or not, with all traffic being affected by the VIP definition and then you're just back to rules defining what is passed or not, and no way to pass it on unintended interfaces.