[Firehol-support] catch-22 with link-balancer?

Spike spike at drba.org
Wed Dec 7 04:15:29 CET 2016


Thank you very much for sharing your insight Costa, both solutions you
presented make a lot of sense and solve the problem nicely. I will
implement #2 as google's dns servers are probably more reliable and likely
to stay consistent than my ISP's RAS. I'm running into some other problems
now, but I'll start another thread for it as it seems something different
that I'm still debugging to the best I can before posting.

thanks,

Spike

On Tue, Dec 6, 2016 at 1:30 PM Tsaousis, Costa <costa at tsaousis.gr> wrote:

> Hi Spike,
>
> Nice you like our tools! Thanks!
>
> You are right to seek something on the far end to ping. This is the right
> way to do it.
> What I do in these cases is this:
>
> Option 1:
> I use the RAS servers of my ISPs. So for each of my links, I add to the
> routing table a static IP on the other side of each link. The RAS is
> normally the first hop on the other side.
>
> Option 2:
> If both links come from the same ISP, I use 2 servers on the internet
> which respond to ping and which I always route from the same link. So, for
> example you can add static routes for 8.8.8.8 via link 1 and another IP via
> link 2.
>
> Keep in mind you can override the check function with whatever else. For
> example, instead of pinging you could use curl to fetch a web page.
>
> I have chosen to do it that way, because I didn't want link-balancer to
> alter the routing table for any reason other than the expected. I didn't
> want to detect somehow that the routing table is messed up and routes
> should be added just of checking if something is alive or not. This would
> require from me to make assumptions on what is expected and what is not and
> most probably it would be impossible for me to predict all the different
> cases out there.
>
> Costa
>
>
>
> On Tue, Dec 6, 2016 at 9:23 PM, Spike <spike at drba.org> wrote:
>
> Dear all,
>
> first post to the list so let me take one sec to thank you all for the
> incredible work, I looked at a dozen fw OSS solutions and firehol was by
> far the cleanest and most immediate to use, great work!
>
> # My setup
> I'm setting up a firewall with 2 uplinks that are both modems connected to
> my firewall through ethernet (ie no ppp devices). I then have one interface
> connected to the lan. By default I bring up all interfaces with static ips
> and no routes, which I intended link-balancer to manage for me. Also,
> because the gws are modems I connect to through ethernet, the modem's lan
> interface may be up but the internet still down, so the default ping of the
> gw is not a good indicator the uplink works.
>
> gw-eth1: 192.168.1.1/24
> gw-eth2: 192.168.2.1/24
> fw-eth1: 192.168.1.2/24
> fw-eth2: 192.168.2.2/24
> fw-eth3: 192.168.3.1/24
>
> # The problem: race condition with ping check
> Like I said pinging the modems on their lan's interface is of no use so I
> setup link-balancer to ping 8.8.8.8. However because I have no default
> routes to being with, that fails and so the routing table are never setup.
>
> Does that make sense? If I change the check section to use the ip of the
> gws everything is fine, but that's not good. If I use G's dns ips then
> routes are not set up.
>
> Is this a catch-22? is there a known solution that I'm missing? I guess I
> could set up a default route in main using one of the two lines to start
> with, but if the server was rebooted when one line is down and the
> interface order is that the the default route is set to the link that does
> not work, then firehol would still fail for the same reason.
>
> It would be ideal, and possible more correct, that link-balancer could
> handle an initial state with no routes and figure out the whole thing based
> on its config (which it has enough info to do I reckon).
>
> thank you,
>
> Spike
>
> _______________________________________________
> Firehol-support mailing list
> Firehol-support at lists.firehol.org
> http://lists.firehol.org/mailman/listinfo/firehol-support
>
>
>


More information about the Firehol-support mailing list