RSHARM
April 14, 2023, 5:39am
1
package by LynxTheCat @Lynx
Just to confirm I understand how this package works
when using separate WireGuard, PBR, CAKE (QoSify or SQM or something else). It is by default
Client>Router>PBR>QoS/SQM>WAN
QoS/SQM treats VPN as "big traffic" can that cause VPN to be of lower priority within network and QoS/SQM doesn't work for VPN.
But when using cake-wg-pbr it is
Client>Router>PBR>QoS/SQM>WAN
That is when using separate packages QoS/SQM, it harms VPN traffic performance but VPN traffic is unaffected when using cake-wg-pbr. Am I right ?
Lynx
April 15, 2023, 7:41am
2
Package was written by me not by @richb-hanover-priv ! But as on GitHub I wasn't able to follow the question.
Maybe someone else on this forum can though. @moeller0 are you able to interpret the question above?
Here is what I wrote on GitHub:
Hmm, I can't follow your nomenclature. Basically if you just use default SQM, cake cannot distinguish the encrypted flows as all encrypted flows are bundled into one stream.
cake-wg-pbr operates as follows: for download, cake-wg-pbr combines the non-VPN flows (from wan) with the VPN flows in their unencrypted state (from the VPN interface); and for upload it relies upon skb->hash preservation, thereby to ensure that cake can regulate everything properly notwithstanding the mixture of encrypted and unencrypted flows.
For download, see:
tc qdisc add dev $wan_if root cake bandwidth 30Mbit besteffort flows nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 92
# ifb interface for handling ingress on WAN (and VPN interface if wg show reports endpoint)
ip link add name ifb-wg-pbr type ifb
ip link set ifb-wg-pbr up
# capture all packets on WAN
tc qdisc add dev $wan_if handle ffff: ingress
tc filter add dev $wan_if parent ffff: prio 2 matchall action mirred egress redirect dev ifb-wg-pbr
# if 'wg show' reports an endpoint, then pass over wireguard packets on WAN and capture all VPN packets
if [ ! -z "$wg_endpoint" ]
then
tc filter add dev $wan_if parent ffff: protocol ip prio 1 u32 match ip src ${wg_endpoint}/32 action pass
tc qdisc add dev $vpn_if handle ffff: ingress
tc filter add dev $vpn_if parent ffff: matchall action mirred egress redirect dev ifb-wg-pbr
fi
# apply CAKE on download using the ifb
tc qdisc add dev ifb-wg-pbr root cake bandwidth 25Mbit besteffort triple-isolate nat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 92
}
For upload, see:
wg_endpoint=$(wg show | awk '{if($1 == "endpoint:"){split($2,a,":"); print a[1]}}')
# apply CAKE on upload (must be besteffort flows nonat nowash to work with the skb->hash preservation)
tc qdisc add dev $wan_if root cake bandwidth 30Mbit besteffort flows nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 92
# ifb interface for handling ingress on WAN (and VPN interface if wg show reports endpoint)
ip link add name ifb-wg-pbr type ifb
ip link set ifb-wg-pbr up
# capture all packets on WAN
tc qdisc add dev $wan_if handle ffff: ingress
tc filter add dev $wan_if parent ffff: prio 2 matchall action mirred egress redirect dev ifb-wg-pbr
# if 'wg show' reports an endpoint, then pass over wireguard packets on WAN and capture all VPN packets
if [ ! -z "$wg_endpoint" ]
then
tc filter add dev $wan_if parent ffff: protocol ip prio 1 u32 match ip src ${wg_endpoint}/32 action pass
tc qdisc add dev $vpn_if handle ffff: ingress
tc filter add dev $vpn_if parent ffff: matchall action mirred egress redirect dev ifb-wg-pbr
fi
See also:
https://lists.bufferbloat.net/pipermail/cake/2020-May/005257.html
FWIW this is also why I never bothered with all the diffserv tinkering. If you have very low bandwidth (say, a couple of megabits), and use applications that tend to continuously use lots of bandwidth that you want to throttle in favour of other traffic (say, bittorrent or cloud backups or something like that), the diffserv-based marking can make sense. But if you don't do any of these, the flow queueing will generally be enough to get you excellent performance on its own.
As for your other qu…