As PTT said it's not a ISO. Though now I look at it the new website does list it as 'Live CD with Installer (on USB memstick)' which is potentially confusing. Another useful utility for writing raw images is Win32 Disk Imager: http://sourceforge.net/projects/win32diskimager/ Steve

Glad to be part of this world we call pfSense!!

???? .JPG) .JPG_thumb)

While your fixing this I would also setup your reverse zone for your rfc1918 address so you don't get this for your dns server Server:  UnKnown Address:  192.168.0.11 if you have PTR for your network you would get something like this the IP of your dns server C:>nslookup Default Server:  pfsense.local.lan Address:  192.168.1.253

another… [image: Untitled2.png] [image: Untitled2.png_thumb]

@stephenw10: I would go separate NICs if I had a choice. Be aware that when you start adding a lot of NICs to a box you might encounter some issues that don't arise otherwise. Like this: https://forum.pfsense.org/index.php/topic,69486.msg379897.html#msg379897 Steve Heh, that box completely imploded when I added some 10Gbe ports on Friday.  Even with queuing disabled in the igb and ix drivers I had to limit the box to 2 cores to get it to boot. My 2.1.1 box (backup in CARP pair) works without any tweaks.

@Damned: I have tried rebooting. It doesn't help very much (/at all) If it's a problem that can be solved by tuning the NIC options then I would expect that rebooting the machine would at least temporarily resolve it (until it runs out of resources again). If the WAN does not come back up after rebooting then I might suspect something at the ISP end objecting to your torrenting. Steve

Not sure where helper got the idea that manual rules have to be empty in the first place?  When you switch back to automatic, the manual rules are not even looked at. You can verify that for yourself with a simple look see with  pfctl -s nat So in manual mode you will notice very specific rules pfctl -s nat no nat proto carp all nat-anchor "natearly/" all nat-anchor "natrules/" all nat on em1 inet from 192.168.1.0/24 to any port = isakmp -> 24.13.xx.xx static-port nat on em1 inet from 192.168.1.0/24 to any -> 24.13.xx.xx port 1024:65535 nat on em1 inet from 192.168.2.0/24 to any port = isakmp -> 24.13.xx.xx static-port nat on em1 inet from 192.168.2.0/24 to any -> 24.13.xx.xx port 1024:65535 snipped the rest xx out part of my wan address. Now look at same rules while in automatic mode pfctl -s nat no nat proto carp all nat-anchor "natearly/" all nat-anchor "natrules/" all nat on em1 inet from <tonatsubnets>port = isakmp to any port = isakmp -> 24.13.xx.xx port 500 nat on em1 inet from <tonatsubnets>to any -> 24.13.xx.xx port 1024:65535 no rdr proto carp all I assure you my manual nats are still there and what do you no the nat rules changed to generic rules using <tonatsubnets>So what I suggest you do is take a direct look at what your nat rules are via  pfctl -s nat when you switch between manual and automatic. [image: manualruleslistedwhileautomatic.png] [image: manualruleslistedwhileautomatic.png_thumb]</tonatsubnets></tonatsubnets></tonatsubnets>

Well, After 15 hours hunting, it turned out to be a digital asset management system (photo and video management) that had gone odd. It runs in a virtual machine hidden in the depths of our system. I ended up turning connections off at the routing switch in the heart of our network until the firewall started up again, then followed the network until I hit on that machine. One reboot later and a happy network. Why is it always a simple solution that takes hours to find :)

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.