@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.

Any update of this problem? Thanks Guys!

Bump.

Yeah this morning I gave up on CDs and did the USB image.  Installed perfectly first try.

@jimp: It'll be a non-issue once we're on FreeBSD 10 and the base is up-to-date. By then will the base still be up to date?  ;)

Does SQUID support listening on multiple interfaces as it can be selected but it seems it does not work? Has anyone got this to work or found a workaround?