I skipped the errors and it installed. Not sure what to think of that, but at least it is working.

I don't see why it wouldn't work, though if this is a critical system I'd probably do a update to 2.0.3 first, just in case.

Just add a firewall rule to the single interface (presumably still WAN) that allows that traffic. Usually if you've only configured one interface such a rule will already be there. You would only add a route like that to allow the pfSense box to access another subnet via some other internal router. Not to allow access to it. This routing would usually be taken care of by your existing router. Steve

Thank you, I think that might have fixed it. Good karma to you :-)

OK that should be good then. No inherent worries there. As with any update, be sure to take a backup first but otherwise, kick it off and see what happens.

Thanks so much guys… I've got some work to do. :-D

Thank you. It helped me.

You can use something like Security Onion to monitor your network.  It's very in-depth security and monitoring tool.  This is probably overkill what you need but wouldn't hurt to take a look.

I think all found out the solution, but: Perhaps that helps for others https://forum.pfsense.org/index.php?topic=75427.0

I assume 65.65.65 is not your real subnet? A common cause of not get internet access on LAN is having set a gateway on the LAN interface. Do you see more than one gateway in System: Routing: Gateways:? A common way to use assigned static IPs would be to use virtual IPs on the WAN and 1:1 NAT them to devices on the LAN. If you need to use the public IPs on the LAN you'll need to disable NAT. Steve

pfflowd would send netflow data to some other netflow server you have on your network. If you want a package to show you per-IP bandwidth in the pfSense GUI, see https://doc.pfsense.org/index.php/How_can_I_monitor_bandwidth_usage

You can't do a transparent proxy on a bridge. It just doesn't work with pf. It's been mentioned/documented before, there may even be a ticket open. It's a limitation of pf.

The pfBlocker package code should reinstall cleanly automatically after an upgrade, and normally does. But note that pfBlocker "disables" itself after being installed/reinstalled/updated. It is "special" in this way (other packages just install and go if there are settings in the config file already). For pfBlocker, you have to go to its settings page and enable/save. But there is no harm in uninstalling first, then upgrade, then install again and enable. It just should not be needed.

Thanks for the tip.  If the kernels are the same between the two then it must be something to do with one of the boot config files like you mention.  I haven't yet figured out what is different between the two loader.conf.local files that causes the driver to not be loaded but at least gives me a good start so I don't go fishing down the wrong hole!

Even 65536 is likely too high. quoting: http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder performance. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. A web server which maxes out at 1000 simultaneous connections where each connection uses a 6 K receive and 16 K send buffer, requires approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Values between 4096 and 32768 are recommended for machines with greater amounts of memory. Never specify an arbitrarily high value for this parameter as it could lead to a boot time crash. To observe network cluster usage, use -m with netstat(1). If each cluster represents approximately 2K of memory, 65536 = 134,217,728 bytes or 128MB or ram, just for mbufs.  In reality, a bit more than this (65536 * (2048 + 256), so around 144MB) is used.

If you have diff NICs, it'll prompt you to re-assign them after restoring the config. Other than that it'll work seamlessly. https://doc.pfsense.org/index.php/Configuration_Backup_and_Restore I prefer manually changing the NIC assignments in the XML before restoring the config, but that's probably mostly a bias of working with systems that tend to be more complex than the average user's, with more NICs, VLANs, etc. and it's faster for me to update the XML than click through the assignments post-restore.

@stephenw10: If you look in the MD5 file: MD5 (pfSense-LiveCD-2.1.2-RELEASE-i386.iso.gz) = f020c4b03ae45eec13adc050d915aa5a The checksum is for the gzipped file not the extracted ISO. The MD5 matched fine for me just now. Steve I see I have exposed my 'noob-ness' yet again. I did indeed run the checksum on the extracted ISO instead of the gzipped file. Thank you very much for clearing that up Steve! I see that people are very active on these forums - what a great community. pffft