Bypass Speedify for specific (V)LAN

Help
1

Hi,

I followed the instructions in Bypass clients to a specific WAN - SmoothWAN to bypass a specific LAN (VLAN actually) to a specific WAN interface.

The issue I ran into is one I did that, that WAN is removed from the “main” routing table, and so when I deactivate Speedify the traffic is forced over the other WAN (which in my case is the less desirable WAN interface).

Once I setup the bypass as instructed, this is what I ended up with:

root@SmoothWAN:~# ip rule
0:      from all lookup local
1:      from 10.26.11.0/24 iif br-lan.2 lookup BYP1
5210:   from all fwmark 0x80000/0xff0000 lookup main
5230:   from all fwmark 0x80000/0xff0000 lookup default
5250:   from all fwmark 0x80000/0xff0000 unreachable
5270:   from all lookup 52
10000:  from 100.98.168.38 lookup BYP1
20000:  from all to 100.98.168.38/10 lookup BYP1
32766:  from all lookup main
32767:  from all lookup default
90010:  from all iif lo lookup BYP1
root@SmoothWAN:~# ip route
0.0.0.0/1 dev connectify0 scope link
default via 10.202.0.1 dev connectify0 proto static
default via 100.65.134.17 dev wwan0 proto static src 100.65.134.16 metric 20
10.26.10.0/24 dev br-lan.1 proto kernel scope link src 10.26.10.1
10.26.11.0/24 dev br-lan.2 proto kernel scope link src 10.26.11.1
10.202.0.0/24 dev connectify0 proto kernel scope link src 10.202.0.2
100.65.134.0/27 dev wwan0 proto static scope link metric 20
123.123.123.123 via 100.65.134.17 dev wwan0
128.0.0.0/1 dev connectify0 scope link
root@SmoothWAN:~# ip route list table BYP1
default via 100.64.0.1 dev eth0 proto static src 100.98.168.38 metric 10
34.120.255.244 dev eth0 proto static scope link src 100.98.168.38 metric 10
100.64.0.0/10 dev eth0 proto static scope link metric 10
192.168.100.1 dev eth0 proto static scope link src 100.98.168.38 metric 10
root@SmoothWAN:~#

You can see that the route via “eth0” has disappeared from the “main” routing table and only appears in the “BYP1” table.

So, if I deactivate Speedify this is what the “main” table now looks like:

root@SmoothWAN:~# ip route
default via 100.65.134.17 dev wwan0 proto static src 100.65.134.16 metric 20
10.26.10.0/24 dev br-lan.1 proto kernel scope link src 10.26.10.1
10.26.11.0/24 dev br-lan.2 proto kernel scope link src 10.26.11.1
100.65.134.0/27 dev wwan0 proto static scope link metric 20
123.123.123.123 via 100.65.134.17 dev wwan0

So all traffic is now heading out “wwan0”. In this case, I’d like traffic in “main” and “BYP1” tables to both use “eth0” and “wwan0” is relegated to “metric 20” and ostensibly unused.

Tim

2

If I understand correctly, you want to failover to interfaces other than wwan0 in case Speedify is off?

3

This is what I am trying to do:

I have 2 WANs:
eth0 == Starlink
wwan0 == Cellular backup

Speedify is configured to use “eth0” primarily but to failover to “wwan0” if Starlink is out (or blocked by a tree).

My “main” routing table (before implementing the bypass from your wiki) was:

default via 10.202.0.1 dev connectify0 proto static
default via 100.64.0.1 dev eth0 proto static src 100.98.168.38 metric 10
default via 100.70.233.128 dev wwan0 proto static src 100.70.233.127 metric 20

So when Speedify is turned off, the traffic will flow via eth0 to Starlink. It turns out I have many sites I access that don’t like Speedify, so I have had to turn it off more than I expected.

One such site is Netflix, and the Speedify internal bypass isn’t working for that, so I decided to put the TVs on a separate VLAN and use the Bypass clients to a specific WAN - SmoothWAN instructions to send them out Starlink (eth0) all the time (bypassing Speedify).

When I implemented the bypass procedure from the wiki, the route to eth0 disappeared from the “main” routing table, so now, when I turn off Speedify, the traffic flows out wwan0 instead of eth0.

I was able to fix this by manually running an ip route add command and adding that route back in. But ideally, the bypass wouldn’t remove the route from the “main” table when it added it to the “BYP1” table.

Hopefully, that is more clear.

Thanks for your help.

Tim

4

Hi checking back in on this issue. I haven’t found a way to consistently get the eth0 route added back into the routing take after following the Bypass clients to a specific WAN - SmoothWAN instructions to create a bypass for a 2nd VLAN on network.

The other side effect of this issue is that when this route is missing, Speedify uses my wwan0 route (cellular) for it’s bypass traffic, which has resulted in slow connections (and expensive cell bills).

I tried putting an ip route add... in /etc/rc.local but tht isn’t working. If cron was running I’d just have it try to add the route every few minutes to make sure it’s in place.

5

Actually, I just figured out how to run the route add in cron, so iI have a workaround for now. If you come up with a fix for the Bypass clients to a specific WAN - SmoothWAN instructions let me know, but otherwise I am set for now.

6

Curious if you have full instructions for your setup, including how to add the cron job etc.? Largely curious as I’m trying to create a specific VLAN that bypasses Speedify as well, and I’m encountering the same problem as you where, eth1 in my case, disappears from the routing table when it gets added to BYP1, which impacts Speedify when it tries to enumerate connections.

7

Here are my notes on this solution.

8

Looks like this works. I should probably note that in my case, I had a second ethernet adapter that acts as a totally different subnet, and it ended up being that I had to add the following on top of your existing instructions:

In Network → Routing:

  1. When adding the IPv4 rule from the original instructions, make sure that the device is pointing towards the second ethernet adapter, not “lan” or “br-lan”.

In Network → Firewall:

  1. Make sure the second ethernet adapter is not in the same firewall category as “lan”.
  2. Add a firewall rule called “lan_cable” which points towards the second ethernet adapter as the device, set input/output/forward to accept.
  3. Add a second firewall rule called “cable” which points towards PortOne (eth1) device, with input/output/forward at defaults, masquerading/MSS clamping checked, and “allow forward from source zones” set to “lan_cable”.
9

Hey @timirvin , just as an update… it seems I have an extreme corner case that is blocking the ability for me to use BYP1:

  1. eth1 loses connectivity to cable internet (interface still up via Technicolor TC4400)
  2. Speedify eventually flags connection as down
  3. When eth1 regains connectivity, Speedify doesn’t pick it up and even removes it from the list of connections
  4. Only way to recover from this is to restart eth1 interface

Now, this has created a situation where if eth1 is on BYP1, even if I restart it, and even if the entry was re-added back to the regular ip route table, Speedify still doesn’t pick it up unless I restart Speedify.

On a sidenote, would you happen to have a good idea how to get the router to recover eth1 in this particular scenario, regardless of whether it was on BYP1? Or would that be more a question for @TalalM ?

EDIT: So I can recover eth1 by adding the following cronjob:

* * * * * /root/checketh1.sh

#!/bin/sh
  
checketh1() {
    if ping -I eth1 google.com -w 2 > /dev/null; then
        :
    else
        logger "disconnected, restarting eth1"
        ifdown PortOne
        sleep 3
        ifup PortOne
    fi
}

checketh1

Now I’m stuck figuring out why Speedify doesn’t detect eth1 when it’s on BYP1, even after it’s been restarted and even when I run the following command and it works:

ping -I eth1 google.com -w 2

So at this point I’m left waiting for @TalalM to hopefully come up with a solution where we can add eth0 or eth1 to a bypass table, without it being removed from the main table (and thus impacting Speedify when it enumerates)

10

Hi, thanks for the feedback, next version will have a UI and will rely completely on firewall markings (L3), not routes which will solve the many issues discussed here.