Hello, I've been using 1.55 for a while (I've tried upgrading to 1.56 but I had some issues because of my old config, so I just stuck with the old version as I didn't have particular problems).
I've a OpenVPN (client) connection from my wndr3800 with Gargoyle to my server. I'd love to pass my voip traffic through the VPN, but then I see that the voip traffic isn't inserted into the "VOIP" (minrtt) queue I'm generally using. Is there any work-around or solution?
OpenVPN and QoS
Moderator: Moderators
Re: OpenVPN and QoS
I have not worked with OpenVPN. Are you saying that neither upload nor download traffic is correctly classified?
Can you post a screen shot of your rules?
Can you post a screen shot of your rules?
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM
Re: OpenVPN and QoS
Yeah... as it is, this isn't going to work.
The problem is that OpenVPN uses another interface, the tun0 interface for traffic. The traffic gets passed to the tun0 interface, and is then encrypted by openvpn, and is then passed out though the standard wan interface (e.g. eth0.2) in a single connection. The QoS rules apply to the wan interface, not the OpenVPN interface so the traffic isn't getting classified as you want it to -- you just get the single encrypted connection of OpenVPN.
Of course, what makes this worse, is that you have the option of applying OpenVPN to ALL traffic or just traffic to other OpenVPN hosts. In the latter case you still have a lot of standard traffic passing out of the wan interface, so it's not clear where the QoS rules SHOULD be applied. I'm not sure what the best solution is here, but I'm open to ideas....
Similar issues apply to Quota rules, only there it's even worse since the exact amount of traffic entering isn't the same as the amount leaving. So, even if I switched to monitoring the tun0 interface (enabling per-host monitoring when OpenVPN is active), the total bandwidth calculation would be wrong due to the overhead introduced by OpenVPN encryption.
The problem is that OpenVPN uses another interface, the tun0 interface for traffic. The traffic gets passed to the tun0 interface, and is then encrypted by openvpn, and is then passed out though the standard wan interface (e.g. eth0.2) in a single connection. The QoS rules apply to the wan interface, not the OpenVPN interface so the traffic isn't getting classified as you want it to -- you just get the single encrypted connection of OpenVPN.
Of course, what makes this worse, is that you have the option of applying OpenVPN to ALL traffic or just traffic to other OpenVPN hosts. In the latter case you still have a lot of standard traffic passing out of the wan interface, so it's not clear where the QoS rules SHOULD be applied. I'm not sure what the best solution is here, but I'm open to ideas....
Similar issues apply to Quota rules, only there it's even worse since the exact amount of traffic entering isn't the same as the amount leaving. So, even if I switched to monitoring the tun0 interface (enabling per-host monitoring when OpenVPN is active), the total bandwidth calculation would be wrong due to the overhead introduced by OpenVPN encryption.
Re: OpenVPN and QoS
It seems a quite difficult situation to manage. In mere theory, the best solution would to queue before tunneling and subtract the tunnel packets from the normal queue. Anyway, this would lead to a problem: how could you understand which is the right part of the VPN stream to queue and where?
I don't think it will be possible. I'm managing in a different way now: different VPNs for different tasks, queuing the UDP vpn packets. But I know, it's a hack, not a solution. Anyway, it's working properly
I don't think it will be possible. I'm managing in a different way now: different VPNs for different tasks, queuing the UDP vpn packets. But I know, it's a hack, not a solution. Anyway, it's working properly