TL/DR : How do you preserve the source IP when passing by inter-vdom, for a packet coming from the internet/public IP ?
We got a Fortigate 100F which is configured in multi-vdom. The first vdom is managed by our ISP, it has an interface connected directly to it's backbone and a default route pointing to it. They have setup it like that for management purposes. The other vdom (lets name it "our vdom") is kind of our LAN side, serves as an hub for an SDWAN architecture, and has a default route to another third-party firewall which has its own internet interface and handle the IDS/IPS.
I need to "progressively" migrate the internet I/Os from the third-party firewall to our vdom on the 100F. For the internet access from our local network, i've created a policy route for specific addresses to go out by the ISP-vdom internet access.
The problem is when i need to access from the internet, on the ISP-vdom public IP, to my LAN which is behind the our vdom. I've created a static route for our LAN subnets to the inter-vdom and appropriate firewall rules, now i got the trafic from internet coming to our vdom. The problem is :
if i don't enable sNAT on the inter-vdom firewall rule, the packet is refused with the "reverse path check fail, drop". Because the source IP is public, i cannot create any static or policy routing to return the packet to the inter-vdom.
if i enable sNAT, the packet is accepted, but the trafic coming from inter-vdom has the source IP of the inter-vdom interface : so i cannot make any firewall rules. The idea is to concentrate our configuration on our vdom only, and let the ISP-vdom with the fewest config possible
Reverse path forwarding is enabled by default on FortiGate and can only be disabled by enabling asymmetric routing which is not a best practice.
Typically all you need to avoid RPF drops is a route for the source IP out the interface it is coming in.
Do you have a default route pointing to your Inter-VDOM link? I assume you would... but maybe not....
EDIT: just re-read your post I see your default route points to your third-party firewall. You can try adding another default route with a higher AD but a lower higher priority and this will still send traffic to your third-party firewall but keep a default route for both interfaces in your table.
Alternatively, and you should consider perhaps configuring an SD-WAN zone/interface because it sounds like you might be heading down that road already. With that in place you won't have any issue with RPF regardless of where your traffic is coming from on the Internet.
Agree with all your statements, but I want to correct one thing. If he will create another default-route with higher AD it will achieve nothing, because it will not be installed in routing-table (probably you meant same AD, higher priority). If you will have default route with same AD but higher priority, this route will be in routing-table, but not used, unless route towards 3rd party firewall will disappear. And at the same time, this will achieve that the traffic will not be dropped by RPF.
"Typically all you need to avoid RPF drops is a route for the source IP out the interface it is coming in." -> not possible because the source-ip is a random public one
"Do you have a default route pointing to your Inter-VDOM link?" -> No, the default route is pointing to the 3rd party firewall.
"Alternatively, and you should consider perhaps configuring an SD-WAN zone/interface" -> If i understand correctly your idea, i create an SDWAN zone containing the inter-vdom interface and the interface to the 3rd-party fw on our vdom on the 100F ?
In my case in don't want to use both of the internet access (3rd-party fw & ISP-vdom) in same time, the idea is to migrate progressively from the 3rd-party firewall to the 100F:
The outcoming trafic from our LAN/our vdom with policy routes (based on source LAN subnet) to got out to the internet by the ISP-vdom.
The incoming trafic by switching progressively each /32 public IP of our pool to the 100F, on the ISP-vdom, creating appropriate dNAT & fw rules, etc.
@akristof you say "[...] unless route towards 3rd party firewall will disappear. And at the same time, this will achieve that the traffic will not be dropped by RPF." -> So if i create the 2nd default route to the inter-vdom interface with higher priority, it will not be used and RPF will let my packet going back by its inter-vdom interface ?
The default route on our vdom is learned dynamically with BGP by one of the ISP router, with "candidate default". I've asked our ISP if it could have an impact if i set a static default route with a lower priority : i thought that it could erase the BGP default route.
Static routes will always take precedence over dynamic routes. So yes if you set a static default route the BGP route will not get installed in the table. You could set the static route AD to match that of BGP.
However, it's probably best in this situation to just create two static default routes for each WAN link and set the priority accordingly. You don't *need* to use the BGP default route. It's always going to point to the VDOM link anyway....
Yes with SD-WAN configured to use your inter-VDOM link and the 3-party FW interface you no longer need to rely on policy routing. You just create SD-WAN policies and route traffic that way. It also avoids the mess of having two default routes with differing priorities, etc.
I don't think the ISP needs to be involved? This would all be configured on your VDOM. The ISP doesn't need to know what you are doing in terms of traffic engineering on your side... But sure fair enough you can talk to them about it...
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.