Skip to main content
commutator
commutator
New Member
March 11, 2021
Solved

Using loopback as blackhole in policy routes

  • March 11, 2021
  • 9 replies
  • 12597 views

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.

    Best answer by commutator

    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

    9 replies

    emnoc
    emnoc
    New Member
    March 11, 2021

    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
    SuperUser
    Toshi_Esumi
    SuperUser
    March 11, 2021

    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
    commutatorAuthor
    New Member
    March 12, 2021

    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
    emnoc
    New Member
    March 12, 2021

    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

     

    sanepunk
    sanepunk
    New Member
    June 18, 2021
    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]
    Terms & ConditionsAccessibility statement
    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!