Currently the upload portion you quoted is completely whitelisted from upload QOS traffic (it shouldn't be).

Since that upload traffic is already present and transversing the eth0 interface, the data just has to be marked so QOS will start accounting for it on the upload portion instead of it being zero-rated.

As for download traffic, the traffic control qos system functions something like this (for non VPN traffic).

The issue with VPN traffic is that ALL data transfer is between eth0 & tun21.
(The traffic never touches br0 so it cannot hit the br0 limiter)

It is easy to segregate download VPN traffic from the remainder all other traffic on eth0.

The hard part ?impossible? part is that I do not know how to do is send the segregated traffic onto the "br0" interface and then forward it back onto the "eth0" interface. This redundant step needs to be done, so it can be part of the br0 bandwidth limiter.

--

So back to my original answer.
Currently QOS + VPN traffic is mostly broken out of the box. (75% broken)
It can be made slightly better, but will remain 50% broken.

ASUS should really fix it ... grumble .. grumble ...
It literally is their job. Doesn't have to be identified, just NOT whitelisted.

Currently the upload portion you quoted is completely whitelisted from upload QOS traffic (it shouldn't be).

Since that upload traffic is already present and transversing the eth0 interface, the data just has to be marked so QOS will start accounting for it on the upload portion instead of it being zero-rated.

As for download traffic, the traffic control qos system functions something like this (for non VPN traffic).

The issue with VPN traffic is that ALL data transfer is between eth0 & tun21.
(The traffic never touches br0 so it cannot hit the br0 limiter)

It is easy to segregate download VPN traffic from the remainder all other traffic on eth0.

The hard part ?impossible? part is that I do not know how to do is send the segregated traffic onto the "br0" interface and then forward it back onto the "eth0" interface. This redundant step needs to be done, so it can be part of the br0 bandwidth limiter.

--

So back to my original answer.
Currently QOS + VPN traffic is mostly broken out of the box. (75% broken)
It can be made slightly better, but will remain 50% broken.

ASUS should really fix it ... grumble .. grumble ...
It literally is their job. Doesn't have to be identified, just NOT whitelisted.

Whitelisting WAN traffic breaks QOS performance completely.

Click to expand...

I thought that was the case, as when I'm streaming video (which is priority 1) and downloading large files over usenet the video will buffer. However, without the VPN client on QOS appears to work fine. Thanks for answering the question.

The script won’t fix the VPNServer data from being not detected by QOS.

Once again,

Upload traffic can be properlly accounted via the script and an additional custom rule.

Download traffic will not be properly accounted for no matter what, due it never touching the bro interface.

Click to expand...

Ok, got it.

That's a shame.

I understood your post I replied to first, the second reply I actually thought that was from another user and I was replying just to be polite (I don't usually use this Tapatalk App, I don't think I like it.)

After rereading your use case, it seems I misunderstood your question.

My reply was towards following VPN configuration:

1) The router can act as a VPN server.
This means if when you are using public WiFi, to keep your data private, you can tunnel into your own VPN server by having the router act as a VPN provider instead of paying for a privately hosted VPN. As an additional bonus you can also access local devices on your home network as if you never left WiFi.

I think your use VPN as follows.

2) You have LAN client connect to the router like normal, but you have set up the router to tunnel all the LAN clients traffic through a private VPN instead of directly through your ISP.

For configuration (2) it might be possible to get VPN traffic fully accounted on both upload and download.

Unfortunately for me, I use the setup defined in configuration (1).

I do not subscribe to a private VPN so I cannot see how the underlying ASUS configuration is actually implemented for configuration (2) and potentially develop rules.

After rereading your use case, it seems I misunderstood your question.

My reply was towards following VPN configuration:

1) The router can act as a VPN server.
This means if when you are using public WiFi, you can tunnel into your own VPN server by having the router act as a provider instead of paying for a privately hosted VPN. That or if you are on LTE, you can still access local devices on your home networking.

I think your use VPN question was as follows.

2) You a LAN client connect to the router. You have set the router to tunnel all the LAN clients traffic through encrypted through a private VPN instead of open to your ISP.

For configuration (2) it might be possible to get VPN traffic fully accounted on both upload and download.

Unfortunately for me, I use the setup defined in configuration (1).

I do not subscribe to a private VPN so I cannot develop and rules or see how the underlying ASUS configuration is actually implemented.

Click to expand...

Yeah, when you wrote "VPN server" in your earlier post I thought you may have misunderstood. However, QOS definitely isn't working with configuration (1). It's not a big deal, its just annoying at times. Thanks for your time.

Yeah, when you wrote "VPN server" in your earlier post I thought you may have misunderstood. However, QOS definitely isn't working with configuration (1). It's not a big deal, its just annoying at times. Thanks for your time.

Sent from my iPhone using Tapatalk Pro

Click to expand...

I developed custom rules to make QOS work properly when the router acts as a VPN client.