OpenVPN Interface under Traffic Shaper? | pfSense v2.3.4



  • Reading around it seems like I should be seeing an OpenVPN interface under Traffic Shaping but it's not there (if I select 2 WANs in the Wizard, it says I only have one). Do I just work with the LAN interface? If so, it's not doing anything. Created floating rules and interface-specific rules but nothing shows up under Status / Queues for qVoIP and qOthersHigh.

    My setup routes all traffic through OpenVPN for site-to-site VPN. I just need VoIP prioritized – which would be one rule: if source is VoIP subnet then set PRIQ Priority 7


  • Rebel Alliance Developer Netgate

    If you assign the OpenVPN interface then it should show up for shaping.

    Shaping on a VPN is always tricky, however, because it's difficult for it to detect that there is contention on the WAN+VPN since they both have to be defined as the same bandwidth.



  • @jimp:

    If you assign the OpenVPN interface then it should show up for shaping.

    Shaping on a VPN is always tricky, however, because it's difficult for it to detect that there is contention on the WAN+VPN since they both have to be defined as the same bandwidth.

    Thinking out loud here…

    I don't shape traffic within my vpn tunnels, I just prioritize traffic going thru my various tunnels, which is a lot easier.  But I've thought about it and if I had the need to shape within vpn tunnels, I'd try to do it like this maybe:

    Tag packets coming in on the lan ports with a unique marker per priority queue.  When the packet hits the WAN interface then just throw it in the proper queue.  This way you don't have to deal with a WAN+VPN bandwidth situation.

    Only thing I'm not sure about is whether or not the tag you slap on the packet when it comes in the LAN gets mangled when the packet is encrypted and before it hits the WAN.  If the tag gets mangled too then this is all for not.  Or I guess ovpn creates a new packet and stuffs the first one in it?  So maybe you need to tag it as it hits the ovpn interface?  Like I said, I've never had the need to shape within tunnels so I haven't bothered setting this up on a test env to try, but if the need ever arises, this is probably what I'd try to do.


  • Rebel Alliance Developer Netgate

    "tag" on a rule does not alter the packet. It is knowledge known only to pf. If you tag in on LAN and the packet "leaves" the VPN then you cannot match that in pf on WAN since it would only be OpenVPN at that point.



  • Ok, that makes sense, but eventually that packet does go out the WAN in one form or another.  Could you tag it on the ovpn interface and identify it again on the wan?  Or is what OpenVPN produces to send out the wan considered a completely new packet unrelated to the original received from the lan?


  • Rebel Alliance Developer Netgate

    The latter.

    A packet leaving OpenVPN is completely encapsulated by OpenVPN – pf doesn't have any way to know that an OpenVPN packet leaving WAN has any relationship to the contents of that packet.

    The only way you can identify traffic like that is with cooperation from the client. If the client sets a TOS bit and you enable "Type-of-Service" (passtos) in OpenVPN it can copy the TOS bits from the inner packet to the outer packet, but that isn't something the firewall controls, it's up to the client.



  • Interesting.  So with some cooperation from the client, it would be possible to do what I'm thinking.  Good to know.  I'll definitely refer back to this thread if/when I ever need to shape within my ovpn tunnels.