to use vlan your switch needs to support it. In other words, it needs to be a managed switch.

I feel like an idiot now.  :-[ We had a power interuption today and i had to bring down the firewall for a few minutes. After the reboot everything works completly as expected.  :)  I have been working with servers and computers for to many years to remember and i know that a reboot is always a good way to eliminate errors. In this case i never thought of it.  :-[ Thanks for the help and support podilarius. /Mike

Gateways are always kept up as much as they can be, and are constantly monitored. Being in a gateway group doesn't trigger anything special about monitoring.

Yup, that did the trick.  Everything is working now. Thank you for the help marcelloc, it was the wan-vlan option.

So I was able to achieve 70,000 pps sustained with an IMIX of UDP packets. However when I run: sysctl net.inet.ip.intr_queue_drops I see the number incrementing quite quickly, net.inet.ip.intr_queue_drops: 645011625 :) Any idea on what I can do here? I booted the IP Input Queue to 3000, then 10000, and stopped at 25000 with no real results. It could be that some of the traffic I'm generating is being dropped anyway. Any opinions on whether or not I should use the traffic shaper? PriQ has always served me well with slower connections, but I'd be apprehensive about having queues that might not be optimized for 1Gb links.

RESOLVED: The route-to behavior can be disabled with a simple floating rule and leaving route-to set to default.  This solves my routing issues by disabling policy routing.  Packets go by the routing table by default with the rule below at the top of the floating rule base.  They can still be specified in your other rules if you want specific rules to use policy routing of course. Action: Pass Interface: (none selected) Direction: out Protocol: any Source: any Destination: any That simple rule at the top of your floating rules will disable the route-to behavior and a rule gets generated in the raw pf rules like this: pass  out  from any to any keep state  label "USER_RULE: Disable route-to by overriding the hidden rule" Just an FYI if someone new to pf firewalling reads this and thinks this will allow all outgoing traffic even traffic from your LAN interfaces going through the firewall then that would be incorrect.  There is a block 'in' enforced by pfsense at the bottom of the rule base.  The in rules is what controls traffic through the firewall in pfsense.  Queue (match) out rules can still be used in floating to enforce QoS queue settings though without affecting pass behavior of other rules in LAN section.

Thanks! Yup upgrading to snap shot solved this problem. 2.0.3-PRERELEASE (amd64) built on Sat Feb 9 21:12:53 EST 2013

Yes.  :)

i might not know if its actually incoming or outgoing or even both. just want to use/combine 2 ISPs i have and then same time with fail-over. thanks for the link i will have to read it first but appreciate your advance help. thanks!

Not possible. The packets are already flowing upon a given path by the time L7 has a chance to classify the traffic. At that point it's impossible for it to re-route the connection since it's already established.

I used 5 virtual interfaces under VMWare and used different subnets for each G/W and WAN interface pair. So far it seems that it works as it should.

it would probably be better to post this in the "firewall" section. i think it might not be easy to only allow gmail (google runs multiple things on the same ip-addresses) It would however be fairly easy to allow all google-services: -create an alias with all know google subnets ( nslookup -q=TXT _netblocks.google.com 8.8.8.8 ) -edit the default "allow all" rule on the lan-tab in pfsense firewalling => change the destination from any to the newly created alias kind regards

Guys it was exremly easy thanks to this video ;-) http://www.youtube.com/watch?v=zrBr0N0WrTY I have just tested access from my office to those public IP addresses and it works great. I believe PC behind the pfSense will work great.

CMB, Thank you very much! That was it. I looked at that rule originally, saw the pass "all", and assumed it was good. Peter

Not really. Here's a list of fixes after 2.0.2: http://doc.pfsense.org/index.php/2.0.3_New_Features_and_Changes Not a 100% complete list, but you can look at the commits on github for the RELENG_2_0 branch.

Somehow it's skipping over the name of the pool there… Try using a different pool name than http, that may be a reserved keyword there that our input validation doesn't reject. Even just something slightly different like "http80" or "httppool" would suffice. And edit each virtual server and save it again after making sure the right pool is selected.