Shaping outbound OpenVpn
-
Running the PfSense OpenVpn package, in server mode, on version 2.1.5R. When I vpn into PfSense via Wan it provides me a 192.168.99.0 gw and 192.168.99.2 ip. Trying to shape the outbound seems daunting compared to "Wan or Lan only" rules.
Looking at the states with a x.x.99.2 filter I see what resembles "openvpn_ip_random_port > wan_ip_random_port > public_destination_ip_random_port. Given that port 1194 isn't showing at these three stages the only rule I can surmise is to place a 192.168.99.2 source address on a Wan out floating rule to assign a queue. Never hits this rule. Tried the same on the OpenVpn virtual adapter and no luck either. Using Tun so rule is UDP only.
Can anyone offer a sample rule for prioritizing outbound traffic from the VPN server (lan>openvpn>internet) ?
Thanks… -
All WAN sees is OpenVPN traffic. It has no idea what's in the tunnel. All it sees are UDP packets between the two endpoints.
You can prioritize the entire VPN tunnel by setting your queues on the firewall rule that permits inbound connections on UDP/1194.
In order to shape traffic inside the tunnel, you would have to set the queues on the
OpenVPN tab or theOpenVPN assigned interface. Or on LAN. These are the places where the characteristics of the traffic inside the tunnel are known.I just tried this. Set a queue named qTest to 1Mb upperlimit on my OpenVPN assigned interface and LAN. Put a rule on LAN for a specific host placing all traffic into qTest.
These are a couple transfers before and after:
$ scp user@remote-host:/boot/initrd.img-3.11.0-15-generic . initrd.img-3.11.0-15-generic 100% 17MB 2.1MB/s 00:08 $ scp user2remote-host:/boot/initrd.img-3.11.0-15-generic . initrd.img-3.11.0-15-generic 100% 17MB 107.9KB/s 02:40Note that this gets complicated because you are shaping inside the tunnel and shaping the tunnel itself. What do you use for bandwidth for the tunnel interface?
But it looks like it can be done to some extent.
ETA: I have no idea if rules on the OpenVPN tab would work since it's a group, not an interface. Probably best to stick with assigned interfaces. In fact, the OpenVPN tab doesn't appear in the traffic shaper config to assign queues to. I guess that's expected.
-
Thanks Derel for responding. Yes, I want to keep it simple, just setting the queue for the tunnel, not its contents. I do have the Nat Wan rule's queue set and get connection hits fine. However interface rules only match inbound traffic. How do I set the queue for outbound openvpn traffic? To my knowledge an inbound packet won't automatically set the same queue to any resulting outbound traffic. It takes a separate floating match rule for this, does it not? And unfortunately OpenVpn traffic has no static ip/port to match outbound traffic at the Wan adapter.
Filtered states reports an outbound connection of OvpnVirtualIp:49198 -> PfSenseIp:47365 -> PublicIp:443. So I thought I could float match the OpenVpnIp as the source IP in a Wan rule. No hits.
-
This is what I do to shape the VPN tunnel to a colo cabinet:
Aliases:
work_vpn - IP address of the outside interface of the OpenVPN server that is listening on port 1195
302_mgmt - the private addresses on the other side of the OpenVPN tunnelThis is from the perspective of my OpenVPN client. I don't run any shaping at the server side as pretty much all the traffic is OpenVPN traffic.
So the first rule is a floating rule on WAN out. It puts all traffic generated by my outbound UDP connection to work_vpn:1195 into qVPN. This is all UDP so there is no reason for an ACK queue. Note that this will also include traffic from the OpenVPN server because the queue is applied to the state.
Traffic in this queue is NOT automatically placed into the qVPN queue on LAN because there's a disconnect - sort of an air gap - between the traffic being passed from OpenVPN to LAN - the state that exists between the local host and any remote hosts over the VPN is completely unrelated to the tunnel connection itself.
So the second and third rules are on LAN out. They put traffic from the remote VPN hosts into qVPN (UDP) and qACK/qVPN (TCP) on LAN. This is less important for me than prioritizing the tunnel itself because the bottleneck is rarely (never) my gigabit LAN.
 -
I'm not sure your sitation applies to mine because you don't run any server side shaping and that's what I need. Your first rule shapes from a private IP connecting to a public vpn server. I already have this rule for client openvpn on the PfSense Lan. I'm doing the opposite. I'm the public vpn client connecting to a PfSense vpn package, via Wan, and need the return traffic to be shaped.
If your 2nd and 3rd rule is Lan out that is opposite the direction I need shaped. When I connect to PfSense with OpenVpn I get these states;
132.245.x.x:443 <- 192.168.99.2:49252 (inbound)
192.168.99.2:49252 -> 24.216.x.x:59248 -> 132.245.x.x:443 (outbound)Where in the outbound connection, shown above, could I create a match rule, which has to be traffic OUT the adapter or leaving PfSense. As far as I know only the Wan adapter can shape upstream traffic and only the Lan adapter can shape downstream traffic. And, to be honest, I'm ignorant to how the OpenVpn virtual adapter behaves, but since it doesn't appear a rule can be set to use virtual adapters, suppose it's not where the solution lies.
Still no viable solution unless I'm missing a critical piece of PfSense behavior.
-
I'm not sure your sitation applies to mine because you don't run any server side shaping and that's what I need. Your first rule shapes from a private IP connecting to a public vpn server. I already have this rule for client openvpn on the PfSense Lan. I'm doing the opposite. I'm the public vpn client connecting to a PfSense vpn package, via Wan, and need the return traffic to be shaped.
If your 2nd and 3rd rule is Lan out that is opposite the direction I need shaped. When I connect to PfSense with OpenVpn I get these states;
132.245.x.x:443 <- 192.168.99.2:49252 (inbound)
192.168.99.2:49252 -> 24.216.x.x:59248 -> 132.245.x.x:443 (outbound)Where in the outbound connection, shown above, could I create a match rule, which has to be traffic OUT the adapter or leaving PfSense. As far as I know only the Wan adapter can shape upstream traffic and only the Lan adapter can shape downstream traffic. And, to be honest, I'm ignorant to how the OpenVpn virtual adapter behaves, but since it doesn't appear a rule can be set to use virtual adapters, suppose it's not where the solution lies.
Still no viable solution unless I'm missing a critical piece of PfSense behavior.
Yeah. You're missing the point.
OpenVPN servers do not initiate connections to OpenVPN clients. OpenVPN clients initiate connections to OpenVPN servers. So in order for you to shape the tunnel on the CLIENT side, you have to match the traffic when the client connects to the server. That, in my case (and, I believe yours), necessitates a floating firewall rule on WAN out for traffic initiated from the client to the OpenVPN server on port 1194 (1195 in my case).
That will shape traffic from the server in BOTH DIRECTIONS because the queue is applied to the STATE, not the traffic itself. There are special considerations for ACK queues, but since this is UDP, that is moot. Shaping traffic in is pretty useless because there's no way to assign the same queue on LAN because the OpenVPN connection is pfSense WAN to pfSense WAN. There are no other interfaces involved on which to apply QoS.
There should be no NAT for the tunnel itself. It will be your Public IP address to your OpenVPN server's public IP address:1194 UDP. THAT's what you need to match to be able to apply QoS to the tunnel itself (and, by extension, all connections inside the tunnel regardless of source, destination, or protocol.)
You are correct in that WAN can only dictate how fast it SENDS data. In order to shape the tunnel from the server to you, you will need to apply QoS on the server side.
If you were to create an assigned interface on the server, you would set the queue on the firewall rule on WAN that allows connections on UDP/1194.
You can apply QoS to connections from LAN to the other side of the tunnel with rules on LAN that specify queues. Those queues will match a queue applied to the corresponding OpenVPN assigned interface of the same name. You can shape connections from hosts on the remote side of the tunnel with queues assigned on the OpenVPN assigned interface. they will match queues on LAN of the same name.
Now you will have THREE layers of QoS WAN/LAN, The OpenVPN tunnel, and traffic within the tunnel. It'll be quite a juggling act.
I never said it was easy or perfect.
-
Yeah. You're missing the point.
OpenVPN servers do not initiate connections to OpenVPN clients. OpenVPN clients initiate connections to OpenVPN servers. So in order for you to shape the tunnel on the CLIENT side, you have to match the traffic when the client connects to the server. That, in my case (and, I believe yours), necessitates a floating firewall rule on WAN out for traffic initiated from the client to the OpenVPN server on port 1194 (1195 in my case).
I know servers don't typically initate which is true in this case. If it requires a floating rule on Wan out do you have a suggested rule example?
That will shape traffic from the server in BOTH DIRECTIONS because the queue is applied to the STATE, not the traffic itself. There are special considerations for ACK queues, but since this is UDP, that is moot. Shaping traffic in is pretty useless because there's no way to assign the same queue on LAN because the OpenVPN connection is pfSense WAN to pfSense WAN. There are no other interfaces involved on which to apply QoS.
I know the Ack requirements for tcp/udp. You earlier suggested a Wan out rule and here you say both directions. Which is it?
There should be no NAT for the tunnel itself. It will be your Public IP address to your OpenVPN server's public IP address:1194 UDP. THAT's what you need to match to be able to apply QoS to the tunnel itself (and, by extension, all connections inside the tunnel regardless of source, destination, or protocol.)
Maybe not in your example, but I have an OpenVpn nat rule matching every Lan nat rule so my client remote connection can connect to all forwarded Lan devices, not just connect to the Lan device GUI itself. It's essential, to match Lan rules or I can't remote connect to anything but PfSense itself. To keep the discussion simple we can ignore this fact.
You are correct in that WAN can only dictate how fast it SENDS data. In order to shape the tunnel from the server to you, you will need to apply QoS on the server side.
If you were to create an assigned interface on the server, you would set the queue on the firewall rule on WAN that allows connections on UDP/1194.
What do you mean "create an assigned interface on the server"? What interface on what server? A virtual interface on the PfSense server?
You can apply QoS to connections from LAN to the other side of the tunnel with rules on LAN that specify queues. Those queues will match a queue applied to the corresponding OpenVPN assigned interface of the same name. You can shape connections from hosts on the remote side of the tunnel with queues assigned on the OpenVPN assigned interface. they will match queues on LAN of the same name.
I wouldn't have hosts and the remote side of the tunnel, only clients. I tried a rule on the OpenVpn virtual interface and it only shaped traffic from the OpenVpn interface to the Lan adapter. Does me no good. I'm trying to read between the lines on what you are trying to convey. Are you suggesting if I rule match to a Wan In and assign to a queue name that connection will retain the queue name thru the Wan, onto the Lan, onto OpenVpn, then migrate around to some of the assigned lan gateways, then return in the opposite direction and transverse these three adapters and out the Wan still retaining the same queue as the packet goes out the Wan back to the remote client? Seems far fetched. Currently I don't have any Lan queues, only Wan queues because I don't shape the Lan I only dynamic limit per ip on Lan out (downstream). I'm not clear what your suggesting here.
Now you will have THREE layers of QoS WAN/LAN, The OpenVPN tunnel, and traffic within the tunnel. It'll be quite a juggling act.
I never said it was easy or perfect.
It shouldn't be this complicated. Thanks just the same for your time to suggest ideas.
-
I know servers don't typically initate which is true in this case. If it requires a floating rule on Wan out do you have a suggested rule example?
First rule here: https://forum.pfsense.org/index.php?topic=88311.msg487589#msg487589
I know the Ack requirements for tcp/udp. You earlier suggested a Wan out rule and here you say both directions. Which is it?
Yeah, that was a mistake.
Maybe not in your example, but I have an OpenVpn nat rule matching every Lan nat rule so my client remote connection can connect to all forwarded Lan devices, not just connect to the Lan device GUI itself. It's essential, to match Lan rules or I can't remote connect to anything but PfSense itself. To keep the discussion simple we can ignore this fact.
Why are you natting? Yes, you need firewall rules to pass traffic, but unless you're dealing with conflicting subnets there's usually no reason to NAT traffic across a VPN.
What do you mean "create an assigned interface on the server"? What interface on what server? A virtual interface on the PfSense server?
I mean create an interface in Interfaces > Assign and assign it to the OpenVPN instance.
I wouldn't have hosts and the remote side of the tunnel, only clients.
Hosts != Servers. Hosts means a host on the network.
I tried a rule on the OpenVpn virtual interface and it only shaped traffic from the OpenVpn interface to the Lan adapter. Does me no good. I'm trying to read between the lines on what you are trying to convey. Are you suggesting if I rule match to a Wan In and assign to a queue name that connection will retain the queue name thru the Wan, onto the Lan, onto OpenVpn, then migrate around to some of the assigned lan gateways, then return in the opposite direction and transverse these three adapters and out the Wan still retaining the same queue as the packet goes out the Wan back to the remote client? Seems far fetched. Currently I don't have any Lan queues, only Wan queues because I don't shape the Lan I only dynamic limit per ip on Lan out (downstream). I'm not clear what your suggesting here.
Now you will have THREE layers of QoS WAN/LAN, The OpenVPN tunnel, and traffic within the tunnel. It'll be quite a juggling act.
I never said it was easy or perfect.
It shouldn't be this complicated.
But it is. Sorry.
What, exactly, do you want to shape? The tunnel itself or traffic inside the tunnel?
I was under the impression you wanted to shape the tunnel itself.
To do this you need a floating rule on WAN out on the OpenVPN client as illustrated above. That will allow you to put the traffic from the OpenVPN client to the OpenVPN server into a queue.
You will also need to create a queue on the OpenVPN server. You will apply this queue to the rule allowing connections to the OpenVPN server. This will allow you to put the traffic from the OpenVPN server to the OpenVPN Client into a queue.
When dealing with the tunnel, no interfaces except the two WANs see the traffic. Ever. It's a service hosted on pfSense itself. There's nothing else you can do.
