SQM with WireGuard and PBR?

Installing and Using OpenWrt
81

@dlakelan does this look about right:

START=50

start() {

        tc qdisc add dev veth0 root cake bandwidth 30Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 60

        ip link add name ifb type ifb

        tc qdisc add dev ifb root cake bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60

        tc qdisc add dev br-lan handle ffff: ingress

        ip link set ifb up

        tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass
        tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb

}

stop() {
        tc qdisc del dev br-lan ingress
        tc qdisc del dev veth0 root
        tc qdisc del dev ifb root
        ip link set ifb down
        ip link del ifb
}
82

does this catch traffic going from LAN to LAN, like a wired device talking to a wireless device?

83

that catches all traffic on br-lan that is NOT local, because:

First, this:

tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass

passes on a packet if it is destined for 192.168.1.0/24.

And this:

tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb

only copies packets not caught by priority 1 above.

So this only copies across the wan/vpn ingress traffic on br-lan to ifb..

84

Do you need cake on br-lan if it’s already catching download traffic on veth0?

In the upload direction you can just use cake on the wan interface for egress since Wireguard will make unique flow hashes available for flow fairness on wan egress.

2 Likes
85

Good point. You are right. Avoid IFB if not needed, right? I guess it's excess computation for little benefit...

.. oh and this means I don't even need script.

86

@dave14305 so like this (with veth-lan member of br-lan, and veth-wan the wan-facing veth into which download traffic is routed)?

root@OpenWrt:/etc/init.d# tc qdisc ls
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
qdisc noqueue 0: dev lan1 root refcnt 2
qdisc noqueue 0: dev lan2 root refcnt 2
qdisc noqueue 0: dev lan3 root refcnt 2
qdisc noqueue 0: dev lan4 root refcnt 2
qdisc cake 8039: dev wan root refcnt 2 bandwidth 30Mbit besteffort flows nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc noqueue 0: dev wlan1-1 root refcnt 2
qdisc noqueue 0: dev wlan0 root refcnt 2
qdisc noqueue 0: dev vpn root refcnt 2
qdisc cake 803c: dev veth-wan root refcnt 2 bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
qdisc noqueue 0: dev veth-lan root refcnt 2
87

I’m out of my league with veth. But simpler is better.

88

better terminology would be veth-br and veth-lan... both of them are facing the LAN but the veth-br is inside the bridge, whereas the veth-lan is external to the bridge and sends towards the bridge.

1 Like
89

Dear @moeller0, @dlakelan, @vgaetera, @dave14305

Thank you all for your patience with me and all the helpful insight.

It seems I have made a mountain out of a molehill, but I have enjoyed the ride.

For anybody wanting to set up SQM in the context of WireGuard + PBR, one easy solution is as follows:

For upload:

  • apply cake on wan using 'flows nonat'
    (as identified in this thread, WireGuard preserves flow hashes available for flow fairness on wan egress - so it really is this simple)

For download:

  • set up veth-br, with peer veth-lan and add veth-br to br-lan
  • route inbound traffic from vpn / wan to veth-lan
  • apply cake on veth-lan
    (this presents an interface that receives only vpn/wan traffic, and so avoids shaping lan<>router traffic)
5 Likes
90

But does it work the way you expect it? :grinning:

91

I am still to apply @moeller0's test, but from my basic testing so far seems to be working. So long as zoom and teams calls go uninterrupted despite Netflix and windows and Android/iPhone software updates then I'm happy.

I think a way to implement this on Asus Wrt Merlin would be to add veth-br to br0, reroute wan and VPN download to veth-lan and then create IFB on br-lan with the tc filter rules I gave above to filter out router-lan traffic. Something like:

ip link add name ifb type ifb
tc qdisc add dev ifb root cake bandwidth 30Mbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 60
tc qdisc add dev br-lan handle ffff: ingress
ip link set ifb up

tc filter add dev br-lan parent ffff: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 action pass
tc filter add dev br-lan parent ffff: prio 2 matchall action mirred egress redirect dev ifb

The QoS override script would facilitate that. But the rerouting would presumably need attention with respect to VPN Director.

Rerouting on OpenWrt is easy once you ditch the main straight jacket VPN PBR implementation and use netifd PBR with simple rules in LuCi (thanks for this insight @vgaetera and for your LuCi work to make this possible).

Merlin would take some convincing even though this would make CAKE work for all cases (no VPN, VPN, VPN with PBR, multiple VPNs etc.).

1 Like
92

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.