[Solved] SQM with a VPN: What interface name? What packet overhead?

Installing and Using OpenWrt Network and Wireless Configuration
1

I currently use both SQM and an OpenVPN client on a 19.07.2 install of OpenWRT.
Should I use pppoe-wan or tun0? Any pros or cons maybe?
What per packet overhead should I add?

All my devices use the VPN client, with no exception.
Otherwise my network interfaces set up is pretty standard with a lan and a wan.
I have a VDSL2 broadband line (80,20) with Vodafone UK (soon moving to EE)
Let me know what other information you would need.
I am adding my current /etc/config/sqm file below.

config 
        option debug_logging '0'
        option verbosity '5'
        option upload '13100'
        option qdisc 'cake'
        option linklayer 'ethernet'
        option qdisc_advanced '1'
        option squash_dscp '0'
        option ingress_ecn 'ECN'
        option egress_ecn 'NOECN'
        option enabled '1'
        option qdisc_really_really_advanced '1'
        option iqdisc_opts 'nat dual-dsthost'
        option eqdisc_opts 'nat dual-srchost'
        option squash_ingress '1'
        option script 'layer_cake.qos'
        option interface 'tun0'
        option download '46200'
        option overhead '34'
2

If all traffic goes through the VPN, then tun0 is the correct device.

Per-packet overhead of OpenVPN depends on encryption settings, so there is no single good answer. E.g., according to this message, OpenVPN with AES-CBC + SHA256 adds as much as 97 bytes of overhead on top of what you already have with VDSL2. So you have 131 bytes of overhead on the line.

However, the above assumes that the speed limit comes from the VDSL2 connection (i.e. physical line properties), which is not the case for you because of the round numbers. I.e. you get what you pay for, not what the line can provide physically. Therefore, only the 97 bytes of OpenVPN overhead are seen by the upstream shaper, and only they matter.

Edit: please post speed test results with and without the VPN, with the SQM set on pppoe-wan and on tun0, respectively. For the purpose of the test, set both upload and download bandwidth to bogus values higher than the actual throughput. The idea is to include the CPU overhead of SQM without actually limiting the speed in any other way.

3

Good, I got that right at least.

I am using ExpressVPN, their cipher is AES-256-CBC and their auth is SHA512 (don't know if the auth is the relevant SHA here...).
I set the overhead to 131 and found that introduces a perceptible delay in webpage loading compared to setting it to 34.

Well, I rounded up the speed numbers. In theory, Vodafone can deliver speeds of up to 79.2 Mbps for downloads and 20 Mbps on my line (as per www.dslchecker.bt.com). In reality, I am capped at 55 Mbps for download and 15 Mbps for upload, 55 Mbps being the guaranteed minimum speed. I never go above, never below.
So you may come to a different conclusion after taking this new piece of info into consideration.

Download and upload speed set to 100 Mbps
There we go:

  • speeds without VPN / without SQM: 50.7 and 14.8
  • speeds with VPN / without SQM: 46.4 and 13.5
  • speeds without VPN / with SQM pppoe-wan: 50.6 and 14.7
  • speeds with VPN / with SQM pppoe-wan: 47.6 and 13.5
  • speeds without VPN / with SQM tun0: the tun0 interface is inactive
  • speeds with VPN / SQM tun0: 47.1 and 13.5

I am below 55 Mbps with the VPN and SQM disabled, this can be explained by the fact I am doing the test on wireless and that, possibly, there is a speed penalty using my router with OpenWRT VS using the Vodafone router. I always obtain higher wireless speeds with the Vodafone router (2 or 3 Mbps higher for download).

4

For bufferbloat mitigation, the capped speed matters, and if it is different from the line speed (and for you it is indeed different), then the line overhead does not matter. Here is how to measure the overhead:

  1. Make sure that absolutely nothing is using the internet.
  2. Install tcpdump on the router.
  3. tcpdump -vpni tun0, ping 8.8.8.8 while tcpdump is running, see the resulting packet size.
  4. tcpdump -vpni pppoe-wan, ping 8.8.8.8 (note that you will see encrypted openvpn packets, not pings, but they are regular and there is no other traffic, so there should be no problem to discern them)
  5. Calculate the difference of packet sizes from steps 4 and 3.

If it is not clear how to interpret tcpdumps, in the example below the IP packet size is 84:

13:27:46.139074 IP (tos 0x0, ttl 63, id 56726, offset 0, flags [DF], proto ICMP (1), length 84)
    5.189.116.201 > 8.8.8.8: ICMP echo request, id 8, seq 1, length 64

In all other aspects than the overhead, the config from the original post is indeed correct.

5
  1. I have only one wireless device connected to the LAN, nothing else is using the internet.
  2. I installed tcpdump fine.
  3. I assume this command line is used when the VPN is on and SQM is set on interface tun0.
    Here is what I got:
    admin@router:~# tcpdump -vpni tun0, ping 8.8.8.8
tcpdump: tun0,: No such device exists
(SIOCGIFHWADDR: No such device)
  4. I assume this command line is used when the VPN is on and SQM is set on interface pppoe-wan
    admin@router:~# tcpdump -vpni pppoe-wan, ping 8.8.8.8
tcpdump: pppoe-wan,: No such device exists
(SIOCGIFHWADDR: No such device)
6

Misunderstanding. Open two terminals. In one, run tcpdump -vpni tun0 (or pppoe-wan), in the other, run ping 8.8.8.8. Interrupt both with Ctrl+C.

7

Got it now.

  1. VPN on, SQM Interface set to tun0
admin@router:~# tcpdump -vpni tun0
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
...
14:55:53.512622 IP (tos 0x0, ttl 64, id 58442, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.0.123 > 8.8.8.8: ICMP echo request, id 22796, seq 2, length 64
14:55:53.521316 IP (tos 0x0, ttl 57, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 10.104.0.123: ICMP echo reply, id 22796, seq 2, length 64
  1. VPN on, SQM interface set to pppoe-wan
admin@router:~# tcpdump -vpni pppoe-wan
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
...
15:23:13.154008 IP (tos 0x0, ttl 64, id 41575, offset 0, flags [DF], proto UDP (17), length 141)
    ispip.port > vpnip.port: UDP, length 113
15:23:13.162053 IP (tos 0x0, ttl 55, id 27411, offset 0, flags [DF], proto UDP (17), length 141)
    vpnip.port > ispip.port: UDP, length 113

I am confident these are related to the ping to 8.8.8.8.
Note that IPs were modified as this is a public forum.
Also, the Per Packet Overhead (byte) is set to 34 for both dumps.

8

So the VPN overhead is 141 - 84 = 57. That's what you should put into the "overhead" box. Also set link layer to "none", because of the external Vodafone shaper that acts at the IP level. The interface should be set to tun0, as already discussed, otherwise there will be no fairness between traffic flows, because the classifier would only see encrypted packets.

Regarding the edit - settings that were changed (where the shaper is placed and what the overhead is set to) are irrelevant for tcpdump.

9

Sorry for the edits afterwards, I have a tendency to go back to my posts!
If I set the link layer to none, then there is no overhead box available. That's in Luci obviously.
Should I amend the /etc/config/sqm file? Or am I just fine selecting Ethernet (VDSL2) and add 57 as an overhead?

10

It's OK to select Ethernet and set the overhead to 57.

11

Great :+1:

Looking at results for tcpdump -vpni pppoe-wan when I don't narrow down my results to just pinging 8.8.8.8, I see a wide range of "lengths", from 109 to 1200.
How should tis be interpreted..? Is this relevant to the setting up SQM anyway...?

12

No, this is not relevant, it means that your router sends or receives packets with these lengths. What's relevant is the relationship between lengths of the original and encrypted packet, that's why we used a program (ping) that sends all its packets of the same length and regular interval.

13

Yes, it makes sense. I can't look at it on its own, I must compare it with lengths observed with tcpdump -vpni pppoe-wan pinging the same addresses.
Thanks patrakov for guiding me through this!

14

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