You can distribute states across multiple WAN interfaces using a load-balancing gateway group to help distribute load across them but you cannot combine two circuits into anything that looks like one.

The wizard is pretty bad. Other than the default floating rules, I ditched the wizard and did everything myself. If possible, I'd just use Limiters and setup fq_Codel, which is pain right now but should be a simple check-box soon. Limiters have the benefit of being able to shape ingress, allowing for easy multi-WAN shaping, and fq_Codel is turn-key for nearly every situation with no config other than setting the bandwidth.

The destination wasn't Steam, it was the proxy.

I suffer for years on slow DSL but ISPs have up the game and are offering more speed for same, even less$ so stay abreast of what they are currently offering.  Comcast even allowing Internet-only, they used to charge big time for this and forcing you to buy double-play, triple-play but no longer.

@SammyWoo: LIMITING won't be so limiting (punt intended) if it allows % of total bandwidth, rather than a fixed number. But I disagree with above, Pfsense KNOWS how much bandwidth you got, Traffic Shaper MAKE you to tell it doesn't it?  So OK, SOHO have no guaranteed BW, but since Pfsense makes you input something, at least there is something to go by. "So OK, SOHO have no guaranteed BW" exactly the problem. Just because you know your car can go 100mph doesn't mean you can do that during rush hour.

Unstable Internet during saturation is symptom, not a cause. I let Bittorrent consume 99% of my bandwidth with no ill effects. I recommend trying to enable FairQ on your WAN interfaces, set your bandwidth to some value less than 100%, start with 80%, and enable Codel on the child queue. Just a few check boxes and like 2 minutes to setup. If that isn't good enough for you, look into fq_Codel limiters.

@SammyWoo: My understanding is, priorities queues are activated on the egress side of interfaces. Thank You!  I'm still messing around with traffic shaping and trying to figure this whole thing out.  So far, I haven't wrecked anything yet.  :)

For floating rules, catch all should be at the top. For normal rules, catch all should be at the bottom.

Not sure if this can be done. If there is a way to configure the rules to say (on the LAN interfaces) if source=LAN IP, place in front of the queue, but then if have heavy subnet to subnet traffic, that will have priority over ALL traffic coming from WAN, would that be acceptable?

I have a feeling the wizard just deals with your typical WAN-LAN, but am sure you can setup the queues/interface(s) manually. Somebody mentions QOS/traffic shaping is just a series of filter rules applied to the egress of interfaces.  If you use the wizard on WAN-LAN, then go back in there and look at the interfaces, you will see the rules applied to the WAN-LAN.  Analyze what they do, then manually configure your own.  Show your chops how much u know this stuff :D

"Main issue is that does not show any activities…. " That is what it looks like to me as well which is really odd.. What does say systat -ifstat 5 show you for your interfaces traffic?  What about say something like [2.4.2-RELEASE][root@sg4860.local.lan]/root: netstat -i -b -n -I igb2 Name    Mtu Network      Address              Ipkts Ierrs Idrop    Ibytes    Opkts Oerrs    Obytes  Coll igb2  1500 <link#3>00:08:a2:0c:e6:20 243692313    0    0 33829938506 166012308    0 220759170807    0 igb2      - fe80::%igb2/6 fe80::208:a2ff:fe        0    -    -          0        1    -        116    - igb2      - 192.168.2.0/2 192.168.2.253        95013    -    -  13184546    48803    -  10963069    - [2.4.2-RELEASE][root@sg4860.local.lan]/root: You can call up a specific vlan with say [2.4.2-RELEASE][root@sg4860.local.lan]/root: netstat -i -b -n -I igb2.5 Name    Mtu Network      Address              Ipkts Ierrs Idrop    Ibytes    Opkts Oerrs    Obytes  Coll igb2.  1500 <link#12>00:08:a2:0c:e6:20  667311    0    0  40451516    4895    0    809821    0 igb2.    - fe80::%igb2.5 fe80::208:a2ff:fe        0    -    -          0        2    -        172    - igb2.    - 192.168.5.0/2 192.168.5.253          42    -    -      20976      133    -      13931    - [2.4.2-RELEASE][root@sg4860.local.lan]/root:</link#12></link#3>

You can use limiters and shape on the WAN for ingress.

Check out this link: https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/ It worked perfectly for me, including giving me top-notch VOIP while bandwidth is fully saturated with upload or download traffic, and perfectly dividing the bandwidth between multiple users. The most salient sections from that post follow. Fixed Limiters These are the more commonly discussed limits from what I've seen. Fixed limits are used when a network operator wants to permit only a very specific upper bound of bandwidth to be used by an individual device, no matter what. Use cases might include public WiFi scenarios, where a network operator wants to discourage people from relying on it being a top quality connection to avoid attracting people who camp out on their network consuming maximum bandwidth all day. Example goal: 256kbps upload limit, 1mbps download limit (enforced per device) The configuration in Firewall > Traffic Shaper > Limiter: Create a new Pipe     Name: Upload     Bandwidth: 256kbps     Schedule: None     Mask: Source addresses (no need to type a number into either of the numeric field boxes in this section)     Create a new Pipe     Name: Download     Bandwidth: 1mbps     Schedule: None     Mask: Destination addresses (no need to type a number into either of the numeric field boxes in this section) The configuration in the applicable LAN-side firewall rule: Advanced > In/Out: Upload / Download Flexible Limits These are less common, and I didn't realize it was actually possible to do this with pfSense until I got Steve's feedback (forum discussions allude to it, but I haven't seen a correct config fully described anywhere yet). The purpose of flexible limits is to allow pfSense to enforce a total cap on user traffic and to dynamically manage the connections based on real network conditions – allocating more bandwidth per device when the network is quiet and less bandwidth per device when many clients are chatting at the same time. In my case, I've seen users report pleasantly usable network conditions consistently even while the network link was 100% saturated -- this is a very good tool to have in your kit for overloaded Internet uplinks (in one case, I've got a large download capacity but a very small upload capacity, and the users would completely overload the upload, resulting in poor conditions for everyone until I implemented this flexible limiter). Example goal: Provide a high quality user experience for hundreds/thousands of devices sharing a business-class cable connection with 300mbps download and 20mbps upload capacity. The configuration in Firewall > Traffic Shaper > Limiter: Create a new Pipe Name: Upload     Bandwidth: 18mbps (put the total amount of bandwidth available here; remember to save a small amount of bandwidth for remote management, downloading packages, etc -- in this example, we're allowing 18mbps for users on a 20mbps line)     Schedule: None     Mask: None     Create a new Queue under Upload     Name: UploadQueue     Mask: Source addresses     Create a new Pipe     Name: Download     Bandwidth: 290mbps (in this example, we're allowing 290mbps for users on a 300mbps line)     Schedule: None     Mask: None     Create a new Queue under Download     Name: DownloadQueue     Mask: Destination addresses The configuration in the applicable LAN-side firewall rule: Advanced > In/Out: UploadQueue / DownloadQueue

I have been struggling with getting limiters to work in 2.4.2 since I installed PFSense about 6 weeks ago. The link posted by @1smallsausage is the first one that (a) actually made sense, (b) describes the process well, and works. The difference between a "pipe" and a "queue" as it pertains to limiters is crucial. Moreover, that having created two sets of limiters on my network, one for "registered" (static assignment) devices and one for "unregistered" (DHCP assignment) devices, I have finally been able to throttle my guests to a 3x1 Mib link and induce a 100ms latency, while allowing registered devices to share the available bandwidth completely equitably, including being able to maintain top grade VOIP quality while full bandwidth downloads/uploads are in progress. The "Flexible vs. Fixed Limiters" article belongs in the docs in the Traffic Shaping category. [Although, personally, I think that limiters probably don't belong as a tab on Traffic Shaping at all, but belong on their own page.]

Posting how I got it working, incase it helps someone else in the future. It was my error of course. When I enabled the traffic shaper and the rules, I just needed to reset the state table of all current connections. I could either reset all states [ http://192.168.X.X/diag_resetstate.php ], or just the states that applied to the devices on my LAN using the filter [ http://192.168.X.X/diag_dump_states.php ]. Both worked. I created an alias call VoipHosts that included the IP address for both T-Mobile devices. I edited the floating rule that was created by the wizard, changed it to include all protocols instead of the default UDP only protocol. At least the LineLink uses both UDP and TCP. This site here really helped. http://pfsensesetup.com/category/setup-guides/ That says this: Traffic shaping should now be activated for all new conections. However, existing connections will not have traffic shaping applied to them, only new connections. In order for traffic shaping to be fully active on all connections, you must clear the states. In order to do this, navigate to Diagnostics -> States. Then click the Reset States tab, check the Firewall state table check box (if it is not already checked), and press the Reset button.

I know this is a bit tab outdated but I have successfully found a way to use intel drivers instead. This method works for xenserver 7.2 (might need some minor changes for 7.1 and below) You have to modify the file /usr/libexec/xenopsd/qemu-dm-wrapper with following after the def main(argv) line: def main(argv): import os import sys argv = [arg.replace('rtl8139', 'e1000') for arg in argv] This will use the intel drivers instead for all the VMs on the xenserver.  I tried a few other ways but this seemed to be the most reliable and consistent for use in a production environment.

This article gives an example of how to do what you are asking for https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/