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.

[emnoc]

Why would you  have a VIP address on another "DC"? What exactly is a DC btw. But it sounds like your  deployment could be in question.

Did you run a diag debug flow? Did you  check the  function for the "correct expected vip" and the other interface?

[tiagomiranda]

Hi ! 

Im forced to have this VIP with a valid IP address of another DC, because my clients cant change the IP address on their application at this moment.

Yeah, a did. I have a Pre Route Check Fail Message.

But the question is, why a VIP attached to one Interface is published on another interface? 

If a go trough the VIP interface and asks for the VIP address, ok, thats the way to go and the VIP should respond.

But if the traffic is coming for ANOTHER interface, why i have a pre route impact when i try to access this IP address?

I have the same scenario with Cisco ASA and it works just fine.

I dont know if this is a Fortigate thing or there is some another option to disable this behavior.

Thanks

[emnoc]

But the question is, why a VIP attached to one Interface is published on another interface?

I guess nobody can answer that unless you showed us the configuration or topology?

So on a pre-route message was that on the  fwpolicy with the VIP or the other interface? Also how is your firewall policy defined? and the VIP defined ?

i would guess the  traffic enter on the other interface destination for the VIP is some how mangle with the interface that's bounded with the VIP.

[Dan_Massameno]

I figured out exactly what causes this behavior.  I had to start a ticket with support to figure it out.  If you have this...

config firewall vip

    edit "vip-server1"

        set extip 203.0.113.1

        set extintf "wan1"

        set mappedip "192.0.2.50"

    next

...it is not "attached" to wan1.  The extip syntax is a complete head-fake.  In fact, this DNAT will happen regardless which interface the packet comes in.  It does do two things:

1. Causes the UI to not allow you to attach this VIP to anything other than the wan1 interface (for the purposes of putting in a policy concerning this VIP.)  This is one of multiple places in the Fortinet GUI that tries to help the operator do the right thing and reduces the number of possible human mistakes.  But that's all it does.

2. Make the flow look like it is coming from this interface.

No matter what interface the packet comes in on, it will receive the DNAT 203.0.113.1 > 192.0.2.50 and it will look like it came in on wan1.  The policies that have wan1 as the source interface will be scanned for a match.

If you want to lock it down there is no GUI way to do it; you have to use the CLI.

config firewall vip

    edit "vip-server1"

        set extip 203.0.113.1

        set extintf "wan1"

        [style="background-color: #ffff00;"]set srcintf-filter "wan1"[/style]

        set mappedip "192.0.2.50"

    next

That will lock it down so the DNAT only happens if the packet comes in on the wan1 interface.  I have tested this on a production network and it works as described.

This is different behavior than how a Cisco ASA would do it and is counter intuitive based on how it is presented to the operator in the GUI.  It is a useful feature to have the DNAT happen regardless of interface (and have the apparent source interface changed,) but you have to watch out for unintended consequences!

Hope that helps.

[rwpatterson]

Plus one on the counter intuitiveness of that "feature"...

[ede_pfau]

Thank you very much for the follow-up, after 7 months...yeez. I always wondered why FTNT had introduced the 'srcintf-filter' option - now it makes sense.

To wrap your head further, there are (rare) occasions where you would define a VIP on the 'any' interface, freeing it's deployment to multiple interfaces (keyword: hair-pin NAT). Here you would exactly not want to have a source filter in effect.

[Dan_Massameno]

It would be really tough to guess what would happen if the VIP was set to any interface.  What would be the new assumed input interface?  What set of policies would the Fortigate scan to figure out if the flow is allowed and what features to apply?  Yikes.  Usually I like to tie things down so that it only has one possible outcome.  The default VIP behavior adds a lot of flexibility to the possible outcomes (i.e., tough to troubleshoot.)  That's why I was excited to find the srcintf-filter syntax.  

FYI: I did my tests on 5.4.1.  I'm not claiming to know for sure all the results of using srcintf-filter.  I haven't seen the souce code!  :)

[rwpatterson]

I agree on the 'any' interface thing and tying down. Troubleshooting is difficult enough without the added odd duplicate source IP.

[ispcolohost]

I found this thread while debugging a destination NAT issue.  Have you all found the srcintf-filter directive actually does something?  I've got a destination nat rule set up via a virtual IP definition mapping a public IP to a private IP that is reachable across VPN.  This successfully rewrites packets from one interface to the private IP which is routed across VPN.  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.  The undesirable interface still tries to be rewritten.