QOS RT-AC87 U build 380.64.2

[shleets]

Does any QOS work with this router on this version of Merlin?

Adaptive QOS
SSL VPN traffic is being shoved into the default Queue instead of other. So I cannot prioritize that traffic when working from home. Even if I give my PC highest priority that does not help.

Traditional QOS - if I set my device to highest it gets shoved to the lowest so I compete in this situation also. Currently, I'm at a loss when woking from home to prioritize my traffic over SSL VPN.

 

[john9527]

What type of VPN? In most cases, a VPN connection will not work with QoS because QoS is only setup to operate with the defined primary WAN interface, not any interface associated with a tunnel.

The only way you may achieve what you are trying to do is to restrict the non-VPN clients in Bandwidth limiter.

 

[RMerlin]

Or, if Traditional QoS worked properly, to set all traffic sent to the remote tunnel endpoint to "normal" instead of "default". Not an option with Adaptive QoS unfortunately.

EDIT: I wonder what would happen if someone disabled NAT acceleration, and created iptable rules to apply the same packet marks as used by Trend Micro... Could someone override it this way?

 

[john9527]

Or, if Traditional QoS worked properly, to set all traffic sent to the remote tunnel endpoint to "normal" instead of "default". Not an option with Adaptive QoS unfortunately.

EDIT: I wonder what would happen if someone disabled NAT acceleration, and created iptable rules to apply the same packet marks as used by Trend Micro... Could someone override it this way?

Not sure it would be that 'easy'....remember the forced change to eth0 interface when QoS is active?

The way I did a workaround on my fork, was to expose the default priority as a selection under traditional qos (which is then applied to VPN connections).....then you can set the rest of the rules relative to this.

 

[RMerlin]

Not sure it would be that 'easy'....remember the forced change to eth0 interface when QoS is active?

It shouldn't matter, as long you are able to set a connmark value on it, and that nothing else overwrites it.

Might be interesting inserting some mangle rules that do nothing but count packets based on their existing marks, to see if what comes out of the TM engine is accessible from iptables. If it is, might be possible to further mangle it before it reaches tc.

 

[john9527]

It shouldn't matter, as long you are able to set a connmark value on it, and that nothing else overwrites it.

Not sure I agree.....the interface is used in setting up the tc qdisc, classes and filters. So you would end up with a mark pointing to the wrong interface. Would be happy to be proven wrong...

 

[RMerlin]

Not sure I agree.....the interface is used in setting up the tc qdisc, classes and filters. So you would end up with a mark pointing to the wrong interface. Would be happy to be proven wrong...

Marks are just integer values attached to a connection/packet, there's no interface information attached to it, unless we misunderstand one another.

 

[john9527]

Marks are just integer values attached to a connection/packet, there's no interface information attached to it, unless we misunderstand one another.

Right, but the mark is read by the defined qos tc filters via the handle parameter.....and that filter is tied to a particular interface (at least that's my understanding )

 

[RMerlin]

Right, but the mark is read by the defined qos tc filters via the handle parameter.....and that filter is tied to a particular interface (at least that's my understanding )

That's correct. But as long you end up marking the connection in iptables, it will have to end up going through that filter. The TM engine doesn't move traffic between interfaces AFAIK (unlike IMQ where you have to copy the traffic to the IMQ interface), it simply marks it as it passes through its engine on that interface.

 

[john9527]

That's correct. But as long you end up marking the connection in iptables, it will have to end up going through that filter. The TM engine doesn't move traffic between interfaces AFAIK (unlike IMQ where you have to copy the traffic to the IMQ interface), it simply marks it as it passes through its engine on that interface.

But the OP was working with a VPN, so the traffic was directed through the tun interface, not the eth0 interface....and the filter wouldn't apply.

 

[RMerlin]

But the OP was working with a VPN, so the traffic was directed through the tun interface, not the eth0 interface....and the filter wouldn't apply.

My idea is that while the traffic inside the tunnel can't be affected, the tunnel itself has to go through the WAN interface, so he could affect the tunnel traffic as a whole.

 

[shleets]

Yes I would be fine affecting the traffic as a whole. That is exactly my intent. Not sure how to go about doing this?