Still fighting for traffic

  • Hi, thanks for taking the time to read trough this :)

    I am failry new to Networking stuff but got my pfSense running since a while now and managed to acheive what I wanted, so I'm a happy puppy (so far) :)

    Lately at home we're started to become more interested in "Video on Demand" services such as Lovefilm/Prime and I found that for 1080p I need to make sure that no other services are fighting for the bandwidth. So I started to look into Traffic shaping… my first tries where not that successfull and I scraped it, but after some time I simply tried again and where more successfull.
    I believe I got a setup wich is a bit special so most of the tutorials or posts I found here did not fully match, but I got it to a point were "most" of the shaping is working.

    My Setup:
    1 box with 2 physical network cards running pfSense 2.1.3
    I'm running 2 OpenVPN clients on the box and 1 OpenVPN server.
    All my traffic to the Internet is routed trough one of the OpenVPN clients to the Internet.
    Only my VOIP Telephone uses the WAN gateway.
    The WAN NIC is connected to another router which is providing the Internet connection (50/10)

    What I want:
    Every queue can have all of the available bandwidth as long as there is no other queue asking for bandwidth. If there is congestion it should get queued as stated in the below table:
    The qLow queue is for any P2P traffic that might happen using BitTorrent or Usenet. This queue can be throttled as needed.

    	     linkshare		realtime	    upperlimit
    VOIP		 2%	   	 1% /0,5mbit
    Stream		40%		40% /20mbit
    ACK 		30%		20% /10mbit
    Web 		15%		12% /6mbit
    DNS 		 5%		 5% /2,5mbit
    Low 		 1%					95%
    Default		 7%		 2% /4,5mbit

    I understood that realtime is the minimum garanteed bandwith that this queue gets if there is congestion. If there is no congestion it can use the value of Linkshare as additional recource. I also understood that if a queue is not using all of theire realtime bandwith this bandwith will be made available for Linkshare.
    Upperlimit is for making sure a queue never uses more than the assigned value at any time.

    What I did:

    All my queues look like the Same (see attachment)

    Apart from the values for realtime and linkshare mentioned in the table above. Also qDefault got the default flag. Queue Length is 50 apart from Web (100) and low (500)

    My Firewall Rules look like shown in the Attachment

    (The pictures are taken from a 2nd box I use for testing, but it looks simmilar on my live box, this box only has one VPN client and no VPN Server, but I guess this makes no difference.)

    I'm not using floating rules as I belive it's not required ? I found, most people using them did not understood that Firewall rules are processed top to bottom (first match wins), so they where using floating rules. Wrong Observation ?

    Did I set this up correctly, do I achieve what I was aiming for ?
    I did test this setup and most of the Traffic goes to the right queues. Is there an elegant way of showing what goes into the default queue ?

    The p2p queue (qlow) seems to get "most" of the traffic correct, but I got the feeling that some of the traffic is entering the default queue.. just a feeling.

    There is still an issue with congestion, qWeb gets full 50Mbit when there is no other traffic, but it gets lowerd dramatically as soon as I run Bittorrent by around 20Mbit. This should not happen.

  • I really got the feeling that traffic gets assigned to the right queue but p2p still dramatically lowers all other queues download speed.
    This was what I tried to avoid and why I used Traficx Sharper, so there is definatly an issue in my configuration, but I was not able to spot it so far.

    Please help !

    Let me know if I need to post more screenshots or if you need more details ?

  • I don't see in any of your posts rules that are putting INCOMING traffic into any queues. That's the real reason that people use floating rules for shaping. The issue is that normal firewall rules are only applied for traffic coming IN through an interface. That means traffic from the WAN never goes through your LAN rules, only through the WAN rules. The exception is floating rules which apply to traffic BOTH entering AND leaving any interface.

    With normal firewalling you only care about traffic entering an interface but with traffic shaping you can only shape traffic queued (leaving an interface) so you actually want to apply the rules to traffic leaving which is why we use floating rules.

  • Thanks for your Reply.

    So are you saying that you are only using floating rules for shaping traffic ?

    I will give it a try on the weekend.

    Action is Pass or Match in the floating rules ? Do I need to tick Quick ?

  • You should be able to do it just with MATCH rules in the floating rules.

  • Hey, no offend, but what you where saying about firewall rules isn't the full truth.

    You can use firewall rules to assign outgoing traffic to gateways for example (as I do it). So you are not open ports with these rules but you can use them to assign traffic to queues too.

    I was playing around yesterday evening with floating rules and had nearly the same result as when using static rules. The only different was that I was not able to assign p2p (bit torrent) traffic to the right queue.

    First issue is I'm not using WAN as my default gateway so I had to create 2 floating rules per ruleset. One for incoming traffic and one for outgoing traffic. pfSense does not allow to not set a direction when using a gateway. But again this worked still fine for outgoing stuff like Web or DNS. Keep in Mind Web broasing is incoming traffic, but this is requested traffic from your client. So I understood that pfSense (and any other router does as well) knows what to do with the incoming traffic and puts it into the right queue, so you don't need an incoming firewall rule foor this kind of traffic. As long as you got the same queue names on all interfaces.

    The second issue was that no matter what I did with floating rules, the p2p Traffic was alsways in the default queue. As soon as I deleted all floating rules and assigned the static rules again, it started to work again. Keep in mind I had to create a outgoing and incoming rule for the traffic ! But this is only for traffic initiated by someone externally.
    I did saw in the logs that when I run p2p and set a port in the software, not all answers where always from this port on my client. So this means I was putting some of the traffic into the default queue but this was ver low, not even worth mentioning.

    I will stick to static rules for now, unless someone can explain me why this does not work… Again. I got the traffic assigned fine, this is no issue to me ! It's that the logic of prioritys and stuff isn't working. p2p Traffic should never ever interefere with other traffic.

    I hope someone can help me with this !

  • Ok, seems that I won't get any further help here.

    I did remove the Shaping yesterday as I was doing some more testing and realized that p2p traffic now was able to consume 50Mbit fine, while with shaping I only got 20 Mbit, so there is either something completely wrong in my setup/logic, or .. don't know ?

    If anyone can shed some light into this, it would be much appreciated.

Log in to reply