I found a problem with VIP with port forwarding when several VIP are mixed binded to different interface. I discover this problem using hairpin policy to reach service from internal machine with public ip address of the service. If the vip I want access are after another vip with bind to different interface, the next vip are not evaluated. Example. VIP1 x.y.z.w:80 -> a.b.c.d:80 ANY VIP2 x.y.z.w:81 -> a.b.c.d:81 ANY VIP3 x.y.z.w:82 -> a.b.c.d:82 ANY VIP4 x.y.z.w:83 -> a.b.c.d:83 ANY VIP5 x.y.z.w:84 -> a.b.c.d:84 WAN VIP6 x.y.z.w:85 -> a.b.c.d:85 ANY connection to x.y.z.w:83 work well since all vip before are binded to any interface but if i try the same with x.y.z.w:85 it doesn't work. Debugging flow I see that VIP4 are matched, instead VIP6 are never matched.
I have checked on fortios 5.6, 6.0 and 6.2 and all have the same issue
Solved! Go to Solution.
Do you have " set match-vip enable" on the policy ? If you feel a problem exists open a support , complaining here is not going to get you a fix. Make support aware that you think its' any issue(s) & that they need to address.
Ken Felix
PCNSE
NSE
StrongSwan
You fix as you know is to change "wan" to any and then it would work. This is a known issue with vips and mix of ANY and interface which could cause issues just like yours
BTW, I ran into that same issue many years ago when looking at a existing fortigate and it took me a while to figure it out.
Ken Felix
PCNSE
NSE
StrongSwan
i don't understand why fortinet doesn't fix this issue.
change bind of vip are a bit complicated, I must remove the vip from all policy and then readd to all disrupting all traffic
I don't think it's a "issue" but just how it works. You have to know the pitfalls of mix and when any is appropiate or not.
Ken Felix
PCNSE
NSE
StrongSwan
I don't agree with you.
If I set any in the interface must be any, regardless if there's other vip with any or other interface.
Other solution may be to be able to create several vip with same ip address, mapped ip address e port but with different bind interface; instead fortigate told be that the vip are duplicated but it's an error since the vip are not binded to the same interface.
VIP1 x.y.z.w:80 -> a.b.c.d:80 ANY VIP2 x.y.z.w:81 -> a.b.c.d:81 ANY VIP3 x.y.z.w:82 -> a.b.c.d:82 ANY VIP4 x.y.z.w:83 -> a.b.c.d:83 ANY VIP5 x.y.z.w:84 -> a.b.c.d:84 WAN VIP6 x.y.z.w:85 -> a.b.c.d:85 ANY
In this example why I can be able to connect to VIP4 from lan interface but not to VIP6?
Also VIP 6 are binded to ANY, why are not evaluated???
What does it mean ANY on VIP6 if aren't ANY since foritos threat as WAN
Do you have " set match-vip enable" on the policy ? If you feel a problem exists open a support , complaining here is not going to get you a fix. Make support aware that you think its' any issue(s) & that they need to address.
Ken Felix
PCNSE
NSE
StrongSwan
We had similar issue on 900D & 600D running code 6.4.5.
Issue.
All VIP was using interface as "any" .
We changed to "WAN" and it worked.
We then reverted to "Any" and it started to work.
we have the following.
Public IP to Server IP/Port
Private IP to Server ip/port.
When we deleted on of the VIP, this issue triggered.
They said its internal BUG and they will work with Developers.
First we hit on 600D and after 2 months we had similar issue on 900D.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1739 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.