Skip to main content
tiagomiranda
tiagomiranda
New Member
June 17, 2016
Question

VIP not attached to ONE interface

  • June 17, 2016
  • 2 replies
  • 19079 views

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.

2 replies

emnoc
emnoc
New Member
June 18, 2016

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
tiagomirandaAuthor
New Member
June 18, 2016

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
emnoc
New Member
June 20, 2016

 

 

 

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
Dan_Massameno
New Member
January 26, 2017

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
rwpatterson
New Member
January 26, 2017

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

ede_pfau
SuperUser
ede_pfau
SuperUser
January 26, 2017

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.

Terms & ConditionsAccessibility statement