Just wondering if anyone has tried this and has words of warning, or wisdom. Our requirement has been raised many times before, but I haven't seen a solution for pre-v6.2. We're running 6.0.12 on a 501E cluster. We want to force certain traffic to one, and only one, member of the sdwan. We have a VoIP appliance with two WAN ports (P1 & P2) and it will handle its own monitoring and failover across these ports. P1 & P2 use private IPs on FG VLANs. P1 has a VIP with a dedicated IP on ISP1. P2 has a VIP on ISP2. SD-WAN rules send P1 traffic via ISP1 and P2 traffic via ISP2, but how to stop it failing over in an outage? The vendor cannot cope with that. I'm considering using policy routes instead of SD-WAN rules to force P1 to ISP1 and P2 to ISP2, and "blackhole policy routes" later in the list to prevent "criss-crossing" during an outage. Blackhole policy routes don't exist AFAIK so my thought is to create a loopback as a dead end. Send the traffic to the loopback and have no policy allowing it to go anywhere from there. These would only come into play in an outage. A tech tip I read advised not to use a loopback as a blackhole. Clearly a blackhole route is cleaner and doesn't involve policy evaluation, clutter the logs, etc. - where they exist. They work nicely to restrict our 3rd party IPsec tunnels to a specific ISP, but those destinations are unique to the tunnels. It's not plausible to identify our VoIP traffic by destination IPs.
If anyone has sent traffic to a loopback as a dead end and discovered anything regrettable, I'd appreciate hearing about it.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
With TAC's help I've found a workable solution so I'm posting it in case someone finds this later needing the same thing. First, thank you Yuri for that information. In my case with this being a policy route it would not take effect when the destination was a loopback, so I could not use it to blackhole certain traffic. I didn't pursue why it didn't work because we need something now using 6.0.12. Our next upgrade will be to 6.4 and this whole problem of limiting certain traffic to one sdwan link even in an outage can then be handled cleanly with security policies.
What we did learn is that if sdwan link is logically down via monitoring (and not physically down) then policy routes (in 6.0) with that link as the destination interface will remain in effect - the traffic does not fail over to another link. The policy route must have the gateway IP specified. If the gateway is 0.0.0.0 rather than a specific IP, then the traffic will fail over when the link is logically down.
So in my case above I just need two policy routes (and no sdwan rules for 192.168.1.7 or 2.7):
1) srcaddr=192.168.1.7 -> output=ISP1,gw=5.5.5.2 2) srcaddr=192.168.2.7 -> output=ISP2,gw=6.6.6.2
Now if either link is down via monitoring the VoIP traffic using that link will not fail over. We needn't worry about just one ISP being physically down because both ISPs use the same LACP port group that spans different switch modules for redundancy.
...Fred
Short answer is no, but if your worried about criss-crossing, block the p1/p2 from a firewall-policy level. Reading your sumamry, I'm guessing the VoIP appliance is attached with public address? if yes why can't you place it behind the fortigate like in a DMZ and then set SDWAN rules for what you want the VoIP appliance to do?
Ken Felix
PCNSE
NSE
StrongSwan
I'm not sure if I understand your phone situation. But speaking of "blackhole" routes, we've been using it since it was 6.0.10 (upgraded to 6.2.7 now) due to a complicated situation involving multiple FGTs, BGP between them over MPLS, and AWS vpn on each FGT. We had to apply a route-map not to advertise this null route to the other FGT though.
config router static
edit 5 set dst x.x.x.x 255.255.255.252 set comment "This customer's common destination over MPLS" set blackhole enable next end xxx-fg1 (xxxxx1) # get router info routing-t all | grep x.x.x.x S x.x.x.x/30 [10/0] is a summary, Null
We use blackhole routes now to tie our IPsec tunnels to a specific ISP, prevent sending non-routable packets to the Internet, etc. All are destination routes. We can't use destination routes here. This question is about policy routes. I've attached a diagram (of relevant subset) of this with example IPs.
We easily added this to our environment as above, but want to prevent just this traffic from failing over. The policy routes could be summarized as:
1) srcaddr=192.168.1.7 -> output=ISP1
2) srcaddr=192.168.2.7 -> output=ISP2
3) srcaddr=192.168.1.7 -> loopback-of-death
4) srcaddr=192.168.2.7 -> loopback-of-death
I'd be surprised if this does not work. My question is whether anyone has tried it and has any warnings.
If there's a better way to stop traffic from P1 failing over to ISP2 when ISP1 is down, I'd love to hear that. Remember we're 6.0 so we can't use an individual SD-WAN member as the destination interface in security policies.
Thanks for reading!
So your doing some type of BCP38 which is good, but I believe your over thinking this. If the policy that allows traffic using your example;
1) srcaddr=192.168.1.7 -> output=ISP1 2) srcaddr=192.168.2.7 -> output=ISP2 3) srcaddr=192.168.1.7 -> loopback-of-death 4) srcaddr=192.168.2.7 -> loopback-of-death
config fire policy
edit 188
set dstint ISP1
set srcaddress 192.168.1.7
set dstaddress SBC-incloud_or_whatever
set service VOIP-protocols
set action accept
set schedule always
next
edit 189
set dstint ISP2
set srcaddress 192.168.2.7
set dstaddress SBC-incloud_or_whatever
set service VOIP-protocols
set action accept
set schedule always
next
end
If your writing it and it's port based only what you place in the policy will flow and follow that rule DO NOT write the rule like this. That would create leaks and violation and specially if SNAT is not being used
You could even write a deny but it's not need unless you have some broader catch all rules
e.g using my rule 188/189 and with a lower placed deny
config fire policy
edit 288
set name deny-leak1
set dstint ISP1
set srcaddress 192.168.2.7
set dstaddress SBC-incloud_or_whatever
set service VOIP-protocols
set action deny
set schedule always
next
edit 289
set name deny-leak2
set dstint ISP2
set srcaddress 192.168.1.7
set dstaddress SBC-incloud_or_whatever
set service VOIP-protocols
set action accept
set schedule always
next
end
Just my two cents observation. the firewall is NOT going to allow traffic unless you write a rule that allows it imho/
Ken Felix
PCNSE
NSE
StrongSwan
In fact I use that technique (i.e., deny certain hosts on one ISP) on my home firewall which runs 6.2.5, but it's not available in 6.0. It was a new feature in 6.2:
"Firewall policies can use SD-WAN members as source and destination interfaces. This allows controlling traffic so that certain types of traffic can only use certain SD-WAN members."
Thank you for your efforts.
Specifically routing to the loopback - I had to do it as Fortigate was refusing to install a route learned via BGP, if the next hop for it was of type blackhole. I did it on production firewall and did not see any added load on CPU/memory and such. I can only second guess that blackhole-d route can be offloaded to hardware maybe, as opposed to Loopback, which is certainly done in CPU only.
With TAC's help I've found a workable solution so I'm posting it in case someone finds this later needing the same thing. First, thank you Yuri for that information. In my case with this being a policy route it would not take effect when the destination was a loopback, so I could not use it to blackhole certain traffic. I didn't pursue why it didn't work because we need something now using 6.0.12. Our next upgrade will be to 6.4 and this whole problem of limiting certain traffic to one sdwan link even in an outage can then be handled cleanly with security policies.
What we did learn is that if sdwan link is logically down via monitoring (and not physically down) then policy routes (in 6.0) with that link as the destination interface will remain in effect - the traffic does not fail over to another link. The policy route must have the gateway IP specified. If the gateway is 0.0.0.0 rather than a specific IP, then the traffic will fail over when the link is logically down.
So in my case above I just need two policy routes (and no sdwan rules for 192.168.1.7 or 2.7):
1) srcaddr=192.168.1.7 -> output=ISP1,gw=5.5.5.2 2) srcaddr=192.168.2.7 -> output=ISP2,gw=6.6.6.2
Now if either link is down via monitoring the VoIP traffic using that link will not fail over. We needn't worry about just one ISP being physically down because both ISPs use the same LACP port group that spans different switch modules for redundancy.
...Fred
@Fred Thanks for the update.
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 |
---|---|
1710 | |
1093 | |
752 | |
447 | |
231 |
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.