You'd be better off using the alc(4) driver from 10 stable. Unfortunately it just missed being included in 10.1. https://svnweb.freebsd.org/base/stable/10/sys/dev/alc/ Steve

Perfect, waiting on RC :D Still stable for now, but I can't restart the server, but its not something we do anyway.

With a PPPoE connection the gateway is allowed to be outside the subnet of the interface where as other types, static/DHCP etc, it is not. If you try to define the gateway manually pfSense will complain as you've found. This is not a problem. The fact that your pfSense VM can check for updates proves that it has WAN side connectivity. When using a virtual machine host and bridging interfaces I do not normally expect the host OS to use those interfaces. I can see how it might use the WAN NIC but there seems to be no reason that it should be using the LAN NIC. I would not expect that to have an IP. If you want to pfSense VM to firewall connections to the host as well then the host should not have an IP address on either WAN or LAN. Instead you add a further virtual NIC that the host OS uses to talk to the pfSense VM. VirtualBox has a special interface type for doing that but I have to admit getting that setup right has tripped me up the few times I've used VirtualBox. Steve

Update 2 Some further progress - purely by chance I unchecked "Skip rules when gateway is down" and I have now got back the behavior expected with LAN policy rules being followed. I set this rule so that traffic was NOT sent to the default gateway when the openvpn link is down - this worked fine in 2.1 but the behavior here has changed. Also, I have a dual openvpn setup, that was nicely load balanced - in this latest version only one of the VPN links is ever used with all the connections going out on the one link. I am struggling to take this further without some help.  Will revert to previous VM for now.

Ah. Hadn't considered that could be an issue. Thanks for coming back with that.  :) Steve

Thanks a lot

new install 2.1.5-RELEASE (i386) built on Mon Aug 25 07:44:26 EDT 2014 FreeBSD 8.3-RELEASE-p16 Dell optiplex GX 270 st-1023 gigabit ethernet cards Disabled onboard nic on install it shows stage 0 and 1 …... Sundance ST-1023 Gigabit Ethernet also seeing this in log kernel: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. trying to find where to change. Thanks for Help.. Jerry

Yes, if you limit an IP address to 96Kbps then pfSense gives it downloaded packets at only 96Kbps. So if it does torrents it will get them at only 96Kbps and will slow down only its own work. For example, I have my user's private mobile phones in a static mapped section of private address space that has a slow limiter like that - they get their mobile phone app updates and fun, but only slowly.

Potentially it could be more reliable and faster than the router. You would have to ensure that you're using only the switch hardware in the wrt54g and it's not doing any routing. That probably means you can't use it's WAN port as that's usually connected directly to the SoC, not the switch. It varies by platform though. Edit: Looking at this diagram it appears you can use the WAN port. The wifi interface is on the separate internal NIC. Steve

https://doc.pfsense.org/index.php/Traffic_Shaping_Guide#Limiter More info, please search at the "Traffic Shaping" forum section ;)

@Mike.Preslicka: I'm having an issue where my pfsense server is randomly crashing and restarting.  I am running running version 2.1.5.  I just submitted a crash report within the last hour.  Can anyone help me to resolve this issue? Thanks, Mike What kind of Atom was it? Was it a C series by chance

Yes, and if you want to run anything else, like Squid or Snort, you'll need further processing power. To give you some idea an Atom D510 is capable of pushing ~50Mbps of encrypted traffic with no other packages running. Steve

Here's an invaluable tool for figuring out your network IP address layout, especially when an ISP gives you a /28, /29, or /30 somewhere in the middle of a /24: http://www.subnet-calculator.com/cidr.php It converts CIDR to netmask and back and shows you your IP address range, of which the first (network) and last (broadcast) IPs are not usable.

A lot more information needed to answer that.  ;) Which Watchguard hardware? What access points? How are they connected? Which pfSense install type? Anything else you thing may be relevant. Steve

YES!! This has been bothering me for months! This fixes it. Thank you. @eduardr: My particular problem was I had set the DNS forwarder service to bind only to the LAN IP's, and it turns out Localhost needs to be added to the list to bind to as well - otherwise the firewall itself cannot resolve the dns name for the update server. This post had the info that clued me in - https://forum.pfsense.org/index.php?topic=68164.15

I could not get Name to work. Got Lucky and Auto worked. Thanks for your Help Jerry

Thanks Steve! That would explain all this certainly. I'm very happy to re-read the page you linked to that shows that ad0 error can be ignored- I was yet to go back and check that was exactly what mine was reporting. Up until now have been having trouble getting the WAN port to pickup a routable address from the bridged cable modem/4 port switch.  Any of the pfSense's hosts' Intel NICs will happily pickup an IPv4 address if I connect them to a network with a DHCP server, but when I connect them to the cable modem's 3rd or 4th port it won't. It shows a link light and negotiates speed & duplex- but won't bring up an IP connection. I've tried assigning WAN to other ports, manually setting duplex to Full and Half. Other devices on my network pickup a routable address if I plug them into the cable modem instead of the pfSense host (LATER EDIT: but only ones which have been conected to it before) In the end I read in another post that this is expected behaviour with cable modems/networks. After re-booting the cable modem it came up fine.  Had some weird things happen during all this with the dhcpd/local interface after completing the webgui's config wizard. Couldn't regain access from the LAN and had to reboot a few times. Maybe my Netgear gigabit RTL card is not getting a warm welcome (it worked well under m0n0wall). Anyway… thanks again. Finally it is time to try the lusher pastures over here at pfSense! On the way home today I found a better rig to use- thrown out in the street just like the old one. An old AMD Sempron 1800+ powered Compaq desktop PC. It has better BIOS configuration screens- and the CPU is a 25W thermal design rather than the 65W Pentium D. The RAM from the old box fits, so now I have 2GB and after disabling all the unused hardware/interfaces such as Audio,I/O, etc. much faster boot and a bigger LED to tell me its on. Yay!

@phil.davis: [There is 64-bit installer for pfSense, so it will be easy to try that. [/quote] Are you sure the installer actually 64bit and not just the resulting OS that is installed?  Because I did download and have been testing with the AMD64 builds and nothing I have done works.  It might also just be a missing efiboot files,  I haven't have time to checkout the disc structure yet.