All inter VLAN traffic will be routed by the Procurve 5412 which is our core switch which is working fine. Any traffic to the internet will be sent to the firewall which is pfsense. If your traffic is simply being sent to pfSense from your core switch (which would mean it's all done at layer 3), you don't need to mess with VLANs at all on pfSense. VLANs are a layer 2 concept, and your switch is dealing with it. Set the default route on your switch to your pfSense address, leave all the VLAN stuff off on your VMWare box and within pfSense, and you should be fine. I am running nearly the same thing (with a Brocade core), and only have to mess with VLANs in pfSense if my switch is not routing them. You will probably, however, want to set up a point-to-point connection between pfSense and your switch (just a /30 will suffice) to prevent pfSense from getting hit with unnecessary broadcast traffic.

If you're using a proxy such as squid, this has been known to happen if you're trying to cache things such as Windows Updates. Squid will sometimes attempt to download a full file or revalidate the cache even if a client stopped the initial request.

Have you tried to ping the printer from windows?

No problem, glad my wild guess proved at least somewhat helpful.  ;) I'm unsure about the status of Squid with multiwan. Certainly what I said, that it always uses the default gateway, used to be true but things may have changed since I last tried it. I'm not running Squid here at home which is the only place I have multiwan connectivity. Time to do some research…. Way out of date: https://doc.pfsense.org/index.php/Troubleshoot_Outbound_Load_Balancing_Issues#Squid_doesn.27t_seem_to_be_using_both_connections Steve Edit: This looks fairly comprehensive, haven't tried it myself though: http://www.communig8.com/articles/64-open-source/137-pfsense-multi-wan-how-to-really-make-it-work

@dreamslacker: I dislike the wizard, it never gives an optimal solution (nor should it since every use-case is different). Nevertheless, you can run the wizard but remove all upperlimits in all queues once it's done.  I've found that it increases latencies across the board (usually when it's active on the queue and occasionally at low loads) for some unknown reason. I've settled on manually setting up my own queues and settings damn nearly since day 1 (pfSense 1.2rc2). I will try your advice, thanks ;) Glad you got your issue solved.. I want to do some more testing in my own DC, trying to find these sub .2 ms response times..  So couple of cisco switches yesterday I pinged from one to the other.. Now the IPs were SVI on a vlan, but switches not doing anything and directly connected was seeing .4 ms roughly..  Which is bit of difference from .1 ms ;) I will be keeping an eye out.. I just personally don't recall seeing such low response times even just local lan with directly connected equipment unless you were pinging loopback, local IP, etc. But I will be paying more attention in the future on the hunt ;) Thx :) I advice you to try to ping a zeroshell box! Just out of curiosity :D

@ptt: https://forum.pfsense.org/index.php/topic,71396.msg389748.html#msg389748 Thank you. Any links about upgrading a service manually? Thanks again.

Also note that a bunch of not-so-high-end switches (e.g. Dell PowerConnect 2xxx) won't allow you to move the management interface to a VLAN other than 1, and require VLAN 1 to be untagged.

Same boat here, intermittent web page loading on 2.1 single WAN cox cable here. I thought it was dns timing out at first, but doesn't matter if we are using dnsmasq, or direct to pubic dns servers. The clearest way I can describe it from a users perspective, is the browser shows 'connecting' for 10-12 seconds before either loading the page or timing out.  It happens once every 10 loads maybe.  Switching back to another router solves the problem, but I'd prefer to use pfsense. I've tried the df bit option, enabling disabling dnsmasq, enabling wan side ping, turning off checksome offloading, I can't figure it out.  I'm about to try out monowall and see if the same thing happens. Hardware wise I'm on: http://www.newegg.com/Product/Product.aspx?Item=N82E16816101364

If the special sites are ones that have quite well-defined IP address(es) (i.e. they are not huge pools of rotating IPs like FaceBook…) then Aliases should work. Say you have WAN and SAT links, and you want some special things to fail over to SAT when WAN is down, then make a gateway group, FailoverToSAT, WAN = Tier 1, SAT = Tier 2. Make an Alias SpecialSites with the names of the sites you want to fail over (myspecial.mailserver.com importantsite.com pfsense.org ...) At the top of your LAN rules, put a rule: Pass, IPv4, protocol any, source LANnet, destination SpecialSites, gateway FailoverToSAT.

Thanks in advance everyone (:

I've finally found the problem! It happens when I route traffic on the same interface using Firewall rules with the State Type (Advanced Features) set on Keep State. Setting it to None solve any kind of lag. Luca

Absolutely. Your isp will issue you two network address blocks. A single ip for your 'wan' and the public block. All traffic to the public block is forwarded to the wan ip. How you deal with it is up to you. You can use the entire subnet on an interface such as lan. You can even split it up. E.g. Your ISP issues you 10.0.0.2/ 30 for wan (with gateway 10.0.0.1) and a block of addresses: 20.0.1.16 to 20.0.1.31. You then assign 10.0.0.2 as static on wan with gateway 10.0.0.1. Now, you can assign the entire block to lan.  So that lan is 20.0.1.17. Your clients can then use 20.0.1.18 to 20.0.1.30 as valid addresses with gateway as 20.0.1.16. Go to outbound Nat, set to manual and do not Nat anything except the pfsense internal loopback address to Wan ip.  You then add the firewall rules to permit/ block traffic as required. Alternatively, you can split the block into 2. You can then attach 20.0.1.16 - 20.0.1.23 as virtual ips to wan. These can be used as Nat addresses for other interfaces. Assuming you have a private LAN as 192.168.1.0/ 24 for internal use. You then assign 20.0.1.25 to say, opt1 interface. Your servers attach to Opt1 and can use 10.0.1.26-10.0.1.30. In this case, you need to make sure that outbound Nat is set to manual mode. You NAT 192.168.1.0/ 24 network to 20.0.1.16 (or any of the other virtual IPs you've assigned to WAN). Do not NAT 20.0.1.24/ 29 at all.  This will ensure that 20.0.1.24/ 29 network (your server network) is routed rather than NAT'ed.