Using loopback as blackhole in policy routes

[commutator]

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.

[emnoc]

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

[Toshi_Esumi]

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

[commutator]

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!

[emnoc]

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

[commutator]

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.

[Yurisk]

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.

[commutator · Accepted solution]

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

[Yurisk]

@Fred Thanks for the update.

[sanepunk]

When a static route to a certain destination is configured with the blackhole attribute, the outbound interface of the route is Null 0, regardless of the next hop of the route. All the IP packets destined for the destination address are discarded without notifying the source host. This route is called a blackhole route. When the network is subject to attacks, you can configure a blackhole route to discard packets destined for a certain address. [link]https://forpc.onl/[/link] [link]https://jiofilocalhtml.run[/link]