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

    Layer7 Skype traffic shaping

    Scheduled Pinned Locked Moved Traffic Shaping
    4 Posts 2 Posters 5.0k Views
    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.
    • P
      Peter.Hardwork
      last edited by

      I just switched to pfSense and trying to configure it to prioritize all my voice traffic using L7 approach. I'm on version 2.1.3 on an Alix board (FreeBSD).

      1. I defined a queue to all my interfaces (WAN/WANOPT/LAN - I have multi WAN) with parameters:
        Name = qVoice, Priority = 5, Explicit Congestion Notification, Bandwidth = 20%, Real m2 = 128Kb, Link m2 = 20%. In case of LAN the new queue is under qInternet which was created by wizard.

      2. I defined a Layer7 container: Name = Voice, Protocol/Struct/Behavior = teamspeak/queue/qVoice, skypeout/queue/qVoice, skypetoskype/queue/qVoice.

      3. Under Firewall Floating added a new rule:
        Pass, Interface = LAN (if I selected WAN, WANOPT it blocked all traffic), Protocol = TCP/UDP, Log = enabled (to see if it is get "filtered"), Layer7 = Voice.

      Then I tried a Skype call and monitored the Firewall log but no entry appeared for my L7 rule. Also watched the Status \ Queues but the qVoice queue was not used at all. I also tried to limit the P2P networks using L7 filter - ofc I tried different protocol and queue but without any success. :-(

      Could you help me what is not correct in these settings?
      Thanks, Peter

      1 Reply Last reply Reply Quote 0
      • S
        sideout
        last edited by

        Under your floating rule you should NOT choose the LAN and then choose the queue  , qVoice and you should have an qACK as well.  It should also be Match with quick option set as well.

        The only time I have used anything other than Match on floating was to use Block but I put those rules at the top. PFSense parses rules top to bottom  then floating then interface rules.  Floating rules are where you define the queue you want the traffic to go into.

        I haven't used Layer7 all that much so I cannot offer you anymore advice but if I have a chance to try and play with it in my lab next week , I can see what I get and post up some results.  I have a multiWAN lab setup as well so it should mirror your environment.

        1 Reply Last reply Reply Quote 0
        • P
          Peter.Hardwork
          last edited by

          Hi sideout,
          Tomorrow I'm going to also spend some time to this. I have some questions however:

          • I tried to specify WAN, WANOPT only but it does not work. Moreover once I enable this floating rule my browser stops working does not display any (external) web pages.

          • I tried to enable all interfaces WAN, WANOPT and LAN - the result is the same. What I'm not sure why should I enable the rule only for WAN interfaces. That will control only the upload… correct me if I'm wrong. I suppose that we need to control both direction/interfaces. I noticed that the wizard creates floating rules only for WAN interface but I do not understand why. My port based floating rules for games use all interfaces WAN and LAN and they work fine - at least I did not notice issues. You have more experience here could you explain?

          • Not sure about specifying the queue in the floating rule. Of course I tried to set it but also clear it. It did not help. Why I'm not sure, because the L7 group itself specifies the queue for each protocol. Since there are no documentation about it :-( I don't know why the L7 group specifies the queue too. I would expect that the L7 group just detects the packets and the floating rule will specify what to do with them. I'm confused here...

          Thanks for your help!!! I would really appreciate if you could find some time to play with this because this area is weakly documented.

          1 Reply Last reply Reply Quote 0
          • S
            sideout
            last edited by

            Okay so I did some lab on this and here is what I found:

            1. Layer7 rule set defined on Traffic Shaper with Skypeout and SkypetoSkpye with option of queue and queue called qSkype.
            a, Set qSkype to have 10% and real time 10% bandwith on LAN and WAN.
            b. Placed Floating rule at top of rule set for TCP / Layer7 chosen.  Used WAN and LAN interfaces.
            c. Killed all session states from test PC.
            d. Tested and I can see qSkype fills up as does qHTTPSteam.  Placed Skype test call and it worked.  Ran speedtest and it worked once but then failed 2nd time and browsing was slow.

            2. Replicated above but removed Floating rule and placed on LAN rule interface.
              a. Left wildcard of any host in.
              b. Same test results as above.

            3. Replicated above but made changes on LAN rule for specific IP of machine I was using.
              a. Tested with same results as in #1.

            So it would seem that the Layer7 part of this is not working very well or is fully implemented as I would expect it to use DPI to see the packet was a skype packet and apply the rule rather than applying all the rules to it.

            Since you can define the incoming connection for Skype you would be able to shape calls coming in for it but since Skype uses any port above 1024 TCP , kind of hard to shape it unless you can get PFSense to see the program calling it and recognize it via the Layer7.

            Like I said , never used Layer7 before as at LAN's not really needed.  This is just what I have found in some early testing.

            If anyone else has any other ideas on how to shape Skype , I would be interested in hearing them.

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