• I have some VoIP traffic running from site B to the SIP server on Site A. This traffic runs over a openvpn tunnel.

    Naturally i see the outgoing traffic on site B landing in the VoIp queue (no matter if floating or lan rules, port or l7 filters)

    The incoming traffic is another story. This i cant catch no matter if i try with floating rules or rules on the openvpn if.

    I did read somewhere that the only possibility with vpn is to create a shared solution, which means voip filter on site A and site B.

    Is this true or did i miss something? Would it be a possible solution to redirect the voip traffic over a bridge (with filters) on site B?


  • So it seems its not possible to catch traffic going out the vpn in both in and out queues!?

    Is this a bug or a (technical) feature? I assume the WAN queue sees already the openvpn traffic and not the encapsulated data, thats why. Correct?

    Is it possible to create a openvpn interface for the shaper rules? Would it help?


  • Sooo, to put openvpn on a bridge seems not possible and usable

    But its possible to create a own Interface for openvpn. In theory it would make it possible to filter the packets. Question is … is it worth a try or does it change nothing?

    i couldnt figure out how to make this openvpn if work till now ... any hints?


  • Bridging solution configured, still just one queue is used.

    OpenVPN bound to an Interface, same story….

    Can somebody enlighten me about the traffic shaper and why it doesnt grip in and out queue on all my tried solutions?


  • I continue to talk to myself….

    Managed to set up traffic shapers for the VPN If. Not sure about the numbers, if the traffic gets catched right. Need to find some tests to check it.

    In the VPN Doc theres this nice comment:

    Type-of-Service : Set the TOS IP header value of tunnel packets to match the encapsulated packet value. Useful if you want to do traffic shaping on the OpenVPN traffic itself, but it does expose some data about the contents of the packet, so it is a potential security risk.

    The question is ... does it work?


  • @tomelgato:

    I did read somewhere that the only possibility with vpn is to create a shared solution, which means voip filter on site A and site B.

    That's the only way it makes sense. Unless, of course, if your VPN link has more bandwidth than your LAN link…

    In a typical setup (LAN bandwidth is equal or exceeds WAN bandwidth), shaping inbound traffic does nothing. All traffic exceeding the WAN bandwidth has already been dropped on the side.

    Concerning TOS: I do not know about TOS in OpenVPN. I do however know that TOS was obsoleted in 1998 (by RFC 2474, IIRC). pfSense only supports DiffServ (http://tools.ietf.org/html/rfc2474). However, as DiffServ reuses the former TOS byte of the IP header, some limited backward comparability exists.

    To translate a TOS value into a DSCP value, divide it by 4. As an example, if you want to use the CS1 PHB, the TOS value is 32 (0x20) while the DSCP value id 8.

    Note that probably no one has tested DiffServ in pfSense with and kind of VPN. Also be aware that DiffServ in pfSense versions 2.1 and earlier had some issues; 2.1.1 works.


  • Ok. The problem is Site A (VPN Server, Voip Server) has a known bandwith, Site B (VPN Client, Voip Client) has a changing bandwith (its some sort of roadwarrior setup).
    So the only solution would be to change the settings on the server every time!?
    Well, this could be somehow done, also per script.

    What i dont get is the difference between traffic shaping on an outbound link or a vpn.

    On the outbound version i have also just control over my side, so inbound traffic shaping via Ack.

    Why doesnt this work for VPN encapsulated packets? I try to shape the traffic before it goes into the tunnel, so from this point of view it looks the same to me like on the normal outbound version.
    (the bandwith sharing between the vpn tunnel and the normal traffic is another story)


  • @tomelgato:

    On the outbound version i have also just control over my side, so inbound traffic shaping via Ack.

    That assumes that your traffic has some feedback mechanism, which allows the sender to throttle its data rate when packets get dropped.

    @tomelgato:

    What i dont get is the difference between traffic shaping on an outbound link or a vpn.

    AFAIR, the traffic shaper sits at the wrong point - at the "physical interfaces" (which can be VLANs as well as real NICs). So it sees only the encrypted VPN tunnel traffic, not the cleartext traffic inside them. This is nice because it allows you to VPNs a higher priority or guaranteed bandwidth. It's absolutely not so nice when you need to shape what happens inside the tunnels.

    One way to work around this might be (never tried this myself) to add a insert second pfSense machine between the main router (which is the VPN endpoint) and the LAN. This second machine would see the unencrypted VPN traffic and should be able to shape it. There might even be a way to do this with a single pfSense machine, a VLAN switch and VLANS formign a loop, but I guess that would be something for people who have too much time on their hands.


  • Thanks for the info, this makes it more clear!

    Unfortunately it seems like there is no easy solution, the version with stacked pfsenses is nice but little bit overkill for a roadwarrior szenario ;)