QoS for OpenVPN site-to-site Tunnel
-
Before we start, I know you cannot shape inside the tunnel. Rather, I was trying to use the DSCP flag on the IP packet to put the OpenVPN packets into different queues. OpenVPN is setup to copy the DSCP flag from the original packet. However, It seems that after the first packet is put into a queue, all the packets after that are put into the same queue regardless of what the DSCP flag is. I have a packet generator running on one end of the OpenVPN tunnel that will send packets with alternating DSCP flags and when I reset the state, the first packet after the reset determines which queue all the remaining packets for OpenVPN will be put into.
More details:
So I have two rules to classify packets:
Rule 1) Any UDP traffic to and from VPN_Endpoints (An Alias that lists the WAN IP addresses for the OpenVPN tunnel) goes into qVPN queue.
Rule 2) To and From any IP address. UDP traffic with the EF DSCP flag set go into qVoIP queue.So then I'll start sending two steams with packet generator. One with the DSCP flag set to EF, the other UDP stream has no DSCP flag set (but it goes across the tunnel). Anyway the first time around all the generated packets go into the qVPN. I then reset the states and all the generated packets go into qVPN again. I reset it again and now all generated packets go into the qVoIP queue. I believe this is occurring because both streams have the same Source/Destionation IP/Port on the WAN (Because both are travelling over the same OpenVPN tunnel).
I've tried setting the "State Type" on the QoS rules to "None" and this doesn't seem to help.
Does anyone know how I can get pfSense to evaluate every packet and not save states? Thank you!
-
States don't change queues, they get set at the time they're created. If states could jump around queues, you could get out of order packets. Just seems like a bad idea.
-
I have a similar vpn situation and what I ended up doing was creating two open vpn tunnels. One I send the voip traffic through and the other I send the rest of my traffic through. Then I can shape them both differently.
-
Harvy66,
I hadn't thought of that, so I did so some looking. It appears by default OpenVPN does allow out-of-order packets with UDP. According to https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage:
–replay-window n [t]
Use a replay protection sliding-window of size n and a time window of t seconds.
By default n is 64 (the IPSec default) and t is 15 seconds.When OpenVPN tunnels IP packets over UDP, there is the possibility that packets might be dropped or delivered out of order. Because OpenVPN, like IPSec, is emulating the physical network layer, it will accept an out-of-order packet sequence, and will deliver such packets in the same order they were received to the TCP/IP protocol stack, provided they satisfy several constraints.
(a) The packet cannot be a replay (unless –no-replay is specified, which disables replay protection altogether).
(b) If a packet arrives out of order, it will only be accepted if the difference between its sequence number and the highest sequence number received so far is less than n.
(c) If a packet arrives out of order, it will only be accepted if it arrives no later than t seconds after any packet containing a higher sequence number.
It could definitely create issues where starvation would cause packets dropping. I'm not saying what I'm trying is necessarily a great idea, but it would work if I could select different queues for different traffic on the same OpenVPN tunnel.
Churchtechguy,
I had thought of that. It doesn't scale well though when you have several offices though. The other idea that I had was traffic shaping the OpenVPN interface. If I assign the interface 10 Mbps, I can traffic shape the WAN and make a queue that matches the OpenVPN traffic and has 11-12 Mbps (OpenVPN interface wouldn't take into account overhead from tunneling). I guess there is several ways to solve this issue, I just don't feel like there is any good way right now with PFSense.
Thanks!