Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Ipsec voip shaping

    Traffic Shaping
    2
    2
    3.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mojo_jojo
      last edited by

      Today I decided to try and shape / prioritize voip traffic over an ipsec vpn tunnel (2.3.2-RELEASE).  I started the traffic shaper wizard with 2 x WAN, 1 x WAN.  The only configuration I set was for bandwidth levels, PRIQ shaping, and enabling of VOIP (I did not set an external SIP provider, just enable qVoIP).  The only thing the wizard did was to create one floating rule (refer to image):  IPv4 * * * * * qVoIP Description: DiffServ/Lowdelay/Upload.  Other than setting the queue to qVoIP, the generated rule had no advanced options set.  I initially thought this rule was just nonsense.  Prioritize all UDP?  I assumed I just didn't understand something and started to test it anyways.  I made a call using an external SIP provider, and voila, the qVoIP queue received the packets.  I expected this as the RTP packets were UDP.  I tested other UDP traffic, and to my surprise, none of the traffic I generated went to qVoIP.  This is strange.  Is there something inside this rule that the web gui doesn't show?  Next I tested a sip call across ipsec to another office.  Nothing went to qVoIP.  I modified the magic floating rule (DiffServ/Lowdelay/Upload) to include the ipsec interface along with the WAN interfaces.  All the RTP traffic from my ip phone over ipsec went into qVoIP for LAN and the WAN.  I thought great, but the rule still scares me.  Since we have DSCP/TOS implemented across all our infrastructure for RTP/SIP traffic, I changed the "Diffserv Code Point" to "EF" for this magic rule and it works the same as before.

      Does anybody understand how this rule could possibly work?  everything seems to work, including WAN qVoIP populate by ipsec packets which is weird to me.

      FYI, I started playing with pfsense about a month ago and started switching out infrastructure at work about a week ago.  I am impressed with this project and I commend the developers for a job well done.  I am tired of writing my own stuff in linux, and I am happy and surprised by how often I said to myself "Hey cool, that just works".

      Rule.png
      Rule.png_thumb

      1 Reply Last reply Reply Quote 0
      • curtisgriceC
        curtisgrice
        last edited by

        From what I have been able to discern, and a quick test, you can use your floating rule set to the IPsec interface and select your queue like any other interface. The traffic will fall into the respective WAN interface and queue for the VPN connection.

        I tested with the following lab setup.

        PC1–pfGreenBay-WAN---pfInternert---WAN-pfMilwaukee--PC2
                      |                                                          |
                      |                                                          |
                IPsecTunnel---------------------------------IPsecTunnel

        I placed all ICMP in my "VoIP" queue and watched the PPS count on the queues as I ping from PC1 to PC2 and saw the packets show in the VoIP queue.

        As for how to "match" the traffic, you can use the DiffServ flags (don't trust them to be there) or by IP/port numbers..... I just re-read you post. I see you are familiar with the DiffServ flags. as for the magic rules? I have no idea I don't work with the wizards much. I don't think I'm telling you anything new at this point but this may help clarify things for other noobs.

        Slow code? Sounds like a good reason to buy more hardware!

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.