Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - bfeitell

Pages: [1] 2
There is a kernel regression that has been identified and patched in FreeBSD that was causing the FreeBSD and PFSense kernel to not boot under KVM/QEMU in Linux on AMD Family 15h processors (Opteron G4 & G5).

Would it be possible to incorporate this patch into 2.4.3, or is it too late?

Here is the bug thread, with links to the patch and commit.


I had a working IPSec tunnel between 2.4.2-RELEASE-p1 and 2.3.5, and upgrading the 2.4.2 install to 2.4.3.a.20180303.2038 breaks the tunnel.

After much puzzlement, I have finally figured out how to get 2.4.0 and 2.4.1 to boot on my AMD radeon based hardware.

A straight boot leads to video corruption that makes the installer completely illegible.

Pressing escape [ESC] immediately after initial boot brings up the kernel loader parameters input screen.  If you press escape more than once, the first attempt to enter a command after the "OK" will fail, but subsequent inputs work fine.

Enter 'gop list' without the quotes, and then hit enter.  You will see a list of numbered available video modes.  After some trial and error, I found that 'gop set 5' worked for me.  After entering 'gop set 5' without the quotes and hitting enter, the return is OK.  Then type 'boot' without the quotes, and hit enter.  When you find the correct mode, the installer will boot correctly, and you will have a fully legible screen.

Before exiting the installer by choosing reboot, enter the shell, and use the editor of your choice to create and save a new file /boot/loader.rc.local containing a single line with 'gop set #', without the quotes, and the number # set to the numeric mode that worked for you, followed by a new line.  In my case the new file /boot/loader.rc.local contains 'gop set 5' without the quotes, followed by a new line.  Do not add your new 'gop set #' line to the existing /boot/loader.rc file, as that will not work.

The specific hardware I am using is a Wyse Z90DW thin client which has 4GB of ram, and a 16GB SATA SSD installed.  The machine features an AMD G-T56N 1.6Ghz dual core APU.

I hope this helps someone.


I am now using 'gop set 8' which corresponds to 800x600x32 on my hardware.  This should support a wider array of monitors.  Gop mode 5, which corresponds to 1152x864x32, works well on my HD monitor, but will likely fail on the old 1024x768 LCD I keep around as a floating head.

It might make sense to set 'gop set 8' as a default in /boot/loader.rc.local in the memstick installer, as this might prevent "out of range" errors when attempting to use older monitors on new hardware in the course of installation.

I can confirm that the new install will boot and display correctly when connected to an ancient 1024x768 LCD monitor using a DVI>VGA adapter, when 'gop set 8' is configured in /boot/loader.rc.local.

Editing the memstick installer to include a /boot/loader.rc.local file containing 'gop set 8' allows the installer to boot when connected to my old 1024x768 LCD monitor, and prevents the "out of range" error that occurs otherwise.

Installation and Upgrades / 2.4.1 and 2.4.0 MBR/ZFS installer is broken.
« on: October 25, 2017, 03:29:21 pm »
I support a number of HP T5730/T5735 thin clients that boot PFSense from USB.  These are 64bit devices with a socketed AMD mobile processor.

I have discovered that no variant of GPT partitioned USB flash drive will boot on these machines.  The hardware is already flashed to the latest available bios.

I have tried doing a ZFS install using an MBR partition scheme, but this does not yield a fully working install of PFSense.

After the system boots, everything seems to work, but there are hidden problems lurking.

While the /boot appears in directory listings, it is not accessible, and an attempt to cd to /boot will fail.

cd /boot yields: "boot: No such file or directory."

Attached are images of the output of "ls -al /" showing that /boot appears in a directory listing, and an image of the failure of an attempt to upgrade the system by choosing 13 from the CLI menu.  The upgrade fails with, "pkg-static: Fail to create /boot/kernel:No such file or directory"

A booted 2.4.1 install shows the same directory listing and cd failure.

Is ZFS on MBR intended to be a supported configuration?


I just managed to install 2.4 onto an 8GB USB flash drive for use in my thin client based firewall.  The install was executed on another AMD based 64 bit machine, since the new memstick installer will not boot with the latest available bios for the target machine.

I executed a ZFS install using MBR partitioning, and zero swap.  The resulting USB key boots perfectly on the T5730, so far as I can tell, but I can't seem to find the /boot directory, or a loader.conf file.  There are some settings I need to tweak for my network hardware, and I have no idea where to put them.  Has anyone encountered this sort of problem?  Is something not mounting correctly?  The machine seems to run just fine, but I have no idea how to proceed.

Here is the directory listing (ls -al) of /

total 110
drwxr-xr-x  22 root  wheel    30 Oct 13 23:05 .
drwxr-xr-x  22 root  wheel    30 Oct 13 23:05 ..
-rw-r--r--   2 root  wheel   887 Oct 10 07:47 .cshrc
-rw-r--r--   2 root  wheel   955 Oct 13 23:05 .profile
-r--r--r--   1 root  wheel  6142 Oct 10 07:47 COPYRIGHT
drwxr-xr-x   2 root  wheel    45 Oct 10 07:58 bin
lrwxr-xr-x   1 root  wheel    13 Oct 10 07:58 boot -> bootpool/boot
-rw-r--r--   1 root  wheel    10 Oct 13 23:05 boot.config
drwxr-xr-x   2 root  wheel     2 Oct 13 17:47 bootpool
drwxr-xr-x   3 root  wheel     3 Aug 18 16:32 cf
lrwxr-xr-x   1 root  wheel     8 Oct 10 07:58 conf -> /cf/conf
drwxr-xr-x   2 root  wheel     3 Oct 10 07:58 conf.default
dr-xr-xr-x   8 root  wheel   512 Oct 13 23:02 dev
-rw-------   1 root  wheel  4096 Oct 13 17:51 entropy
drwxr-xr-x  29 root  wheel   180 Oct 13 23:05 etc
drwxr-xr-x   4 root  wheel     4 Oct 13 22:13 home
drwxr-xr-x   4 root  wheel    55 Oct 10 07:58 lib
drwxr-xr-x   3 root  wheel     4 Oct 10 07:58 libexec
drwxr-xr-x   2 root  wheel     2 Oct 10 07:47 media
drwxr-xr-x   2 root  wheel     2 Oct 10 07:47 mnt
drwxr-xr-x   2 root  wheel     2 Oct 10 07:47 net
dr-xr-xr-x   2 root  wheel     2 Oct 10 07:47 proc
drwxr-xr-x   2 root  wheel   144 Oct 10 07:58 rescue
drwxr-xr-x   3 root  wheel    11 Oct 13 23:02 root
drwxr-xr-x   2 root  wheel   124 Oct 10 07:58 sbin
lrwxr-xr-x   1 root  wheel    11 Oct 10 07:47 sys -> usr/src/sys
drwxrwxrwt   5 root  wheel  1536 Oct 14 01:04 tmp
drwxr-xr-x  13 root  wheel    13 Oct 13 22:13 usr
drwxr-xr-x  15 root  wheel   512 Oct 13 23:05 var
drwxr-xr-x   2 root  wheel     2 Oct 13 17:46 zroot

Here is a listing of /bootpool

total 9
drwxr-xr-x   2 root  wheel   2 Oct 13 17:47 .
drwxr-xr-x  22 root  wheel  30 Oct 13 23:05 ..

Here is a listing of /zroot

total 9
drwxr-xr-x   2 root  wheel   2 Oct 13 17:46 .
drwxr-xr-x  22 root  wheel  30 Oct 13 23:05 ..


The monitoring graphs for NTP are very wrong.  The maxima and mimima for the offset are being calculated as signed numbers, rather than as absolute values relative to zero.

Please see the attached image showing NTP for an 8 hour span at 1 minute resolution.  The hover box shows an offset of -0.01 ms, which should be presented as the minimum offset in the chart below.  Instead the chart shows a minimum of -0.54 ms, which is the signed number minimum offset, but the absolute value maximum.  Likewise the maximum is shown as 0.30 ms, which I expect is the signed maximum offset over the time period, but is not the correct absolute value maximum, which is |-0.54| ms.

There is an inconsistency between the way the GUI parses IPv6 inputs dues to a character filter on the General Setup page.

A numeric IPv6 address may be added under Services/NTP, and the system will use the IPv6 address just fine.  Due to the character limits in place on the System/General Setup page, the valid IPv6 address entered on the Services/NTP page breaks future changes to the System/General Setup page, which will thrown an error on save.

The General Setup page filter excludes the colon ":" which is necessary to input a properly formatted numeric IPv6 address.

Attempts to save on the General Setup page show an error as follows:

(edited for clarity, spelling, and grammar)

Hello all:

This is sort of a feature request, and I'm not sure where the post belongs.  Please relocate it if need be.

It has been my experience that it is common practice to block IPv4 RFC 1918 private addresses on the WAN interface, where the WAN connection is expected to have a proper world routable IPv4 address.

Under 2.3.3, the toggle for this blocking also invokes blocking for IPv6 RFC 4193 LINK-LOCAL addresses.  IPv6 LINK-LOCAL addresses are different from RFC 1918 "private" addresses, and blocking the RFC 4193 addresses can break basic IPv6 functionality.

In my specific use case, blocking RFC 4193 LINK-LOCAL addresses on the WAN breaks IPv6 prefix delegation by my ISP when I request a /56 address block. I can still get a WAN IPv6 address, and the first tracking subnet can get its /64 delegation, but if RFC 4193 addresses are blocked, successive subnets will not get their unique /64 delegations. 

I think there really should be two check boxes available on each interface so that RFC 1918, and RFC 4193 addresses may be blocked or admitted independently of each other.

I would like to be able to block RFC 1918, yet admit RFC 4193 addresses, but cannot because of the way the two have been conjoined in the GUI interface.


pfBlockerNG / pfBlockerNG v. 2.1.1_4 not blocking IPv6?
« on: September 22, 2016, 11:29:56 am »
Hello all,

I am running pfBlockerNG v. 2.1.1_4 on 2.3.2-RELEASE (i386), and have selected countries to block using GeoIP.  I have allocated enough memory, and reloads and updates work fine with no errors.  Under prior versions, before the GeoIP2 changes I would regularly match and block inbound IPv6 packets.  With this latest version, which is the first GeoIP2 version I have running smoothly, I see no matches on IPv6 traffic at all. 

Am I missing something, or is something broken with respect to IPv6?

(I know that blocking the world is discouraged, but it is my choice.  This post is not about that.)

Attached is a snapshot of a portion of the pfBlockerNG dashboard which shows the blocked packet counts at zero for IPv6.


Packages / LADVD problem and suggestion
« on: November 03, 2015, 02:42:30 pm »
I recently ran into a problem with the LADVD package in connection with CDP and LLDP.

My network is very simple, and the management interface of my PFSense box is on the native vlan for the interface, vlan 1, and LADVD works perfectly in my environment.

My friend's network is a bit more complex, and his management interface is not on vlan 1, although vlan 1 is trunked along with several other vlans to the PFSense box.  His PFSense box has no interfaces configured on VLAN 1 at all.  The GUI for LADVD cannot be configured to give a working install in his environment.

I was able to start LADVD at the command line, and point it directly at the parent interface for my friend's internal vlans (in his case, em1), and then LADVD works just fine, and the pfsense box shows up as a CDP neighbor on his Cisco switch, and the switch showing up as a CDP neighbor in LADVD status.

I suggest that the parent interfaces be made available through the LADVD gui, since all of the link layer discovery protocols it supports travel on vlan 1.

I have tried to set up a shellcmd to start LADVD with the parameters that work, but I haven't been able to test it via reboot, as the box in question is currently in production.  The option of binding to parent interfaces should be presented in the GUI.

The command that works for me is "ladvd -a em1".

Maybe this well help someone else who runs into the problem.


Wireless / Atheros AR9280 testing, settings, craziness, success, YMMV
« on: April 26, 2015, 04:46:14 am »
I picked up a bunch of AR9280 based mini-pcie cards on eBay (hint, search for FCC IDs and buy them for less than $7 used).

After playing around I have finally been able to get some good performance numbers out of these cards with testing done in N, and pure A.

This might well break your toys, so note your original settings and be careful.  I'm still looking at latency issues, even though throughput was the ultimate goal.

I am using these settings on an asymmetric connection from Optimum/Cablevision on Eastern Long Island (NY), and I seen to be able to match or come close to wire speed for this hardware, and saturate the connection over wireless using both 802.11A and 802.11N.

Running speed tests on I noticed that connections across the wireless card tended to stutter, and I intuited that there was an issue with the send and receive buffers. 

sysctl -a hw.ath dumps the parameters that may be tweaked for the AR9280.  Some tweaks below relate to the AR9280 stuck beacon issue.

Here are the settings I'm using:

hw.ath.longcal: 30 (custom)
hw.ath.shortcal: 100 (default)
hw.ath.resetcal: 1200 (default)
hw.ath.anical: 100 (default)
hw.ath.rxbuf: 2048 (custom)
hw.ath.txbuf: 896 (custom)
hw.ath.txbuf_mgmt: 80 (custom)
hw.ath.bstuck: 16 (custom)

I also played with tcpinflight, and its relevant upper and lower limits, but I'm not sure it makes a difference or even works in FreeBSD 10. 

(system tunables)
net.inet.tcp.inflight.enable   #Enable TCP Inflight mode#: 1
net.inet.tcp.inflight.max #recommended is 1073725440 default in no entry#:   1073725440   
net.inet.tcp.inflight.min  #recommended is 6144 default is no entry#: 3584

*The last tweak was setting:
net.inet.tcp.experimental.initcwnd10: 1

All of the non-standard settings are now entered as custom entries in System->Advanced->System_Tunables

Research on these toggles is left as an exercise for the reader.

If your connection is symmetric, or less lopsided than mine (~18+M-down/~5+M-up), you might try raising the value for hw.ath.txbuf, and hw.ath.txbuf_mgmt (which I expect is the buffer for management beacons).  I just tested buffer values moving up from the default settings in increments divisible by 16.

I have attached a sterile PNG of a representative run from my Macbook Pro connected via 5GHz 802.11n on channel 153.
I hope this helps someone out.


[HARDWARE: HP-T5730 1G Ram, 1G Flash, upgraded from a Sempron to an AMD Athlon X2 Dual-Core Mobile L310 - AMML310HAX5DM.  WAN NIC is the onboard bge0 interface.  LAN NIC is a Trendnet TU2-ET100 which uses the axe driver and presents as ue0. WIFI: Hon Hai/ HP AR9280 AR5BXB92 MAC: 00:24:2b:XX:XX:XX.  SOFTWARE: nanobsd (1g)/2.2.2-RELEASE (amd64)/built on Mon Apr 13 20:10:22 CDT 2015/FreeBSD 10.1-RELEASE-p9.]

When freeradius2 is installed on nanobsd.

The cause seems to be the ephemeral nature of files in /var, which on nanobsd exists as a ramdisk.

The freeradius2 package requires the following directories:


My workaround is to install the shellcmd package and add the following two earlyshellcmd entries:

mkdir -p /var/log/radacct/datacounter
mkdir -p /var/log/radacct/timecounter

The -p flag tells mkdir to create the intermediate /var/log/radacct directory as well, if it is missing.

I am using this solution with PFSense 2.2.2-RELEASE (i386) nanobsd, and freeradius2 2.2.6_3 pkg v1.6.11.

This workaround should be built into the startup script for the package.

I hope this helps someone.


KEY WORDS: freeradius2 freeradius radius nanobsd start restart boot reboot fail fails failure

Traffic Shaping / USB interfaces and altq, axe
« on: February 08, 2015, 03:32:59 am »
I know that USB ethernet interfaces are not a preferred solution when using pfSense but I have found that stability is much improved in pfSense 2.2, which is based on FreeBSD 10.1.  I am running the NanoBSD version.

I am using a cheap Trendnet TU2-ET100 (HW v.4.0R), and it has been perfect under 2.2, and is supported by the axe driver.  The interface is presented as ue0. There is one problem.  While the axe driver supports altq, the ue driver does not. 

I found a useful post on the pfSense mailing list which offers a partial solution:

By editing /etc/inc/ and adding "ue" to the list of drivers supporting altq, the traffic shaper may be used with my USB NIC.  Unfortunately, this is an ephemeral change that will likely be overwritten when pfSense is upgraded.  If anyone is aware of a way to make this change stick through an upgrade, I would love to know.

After the edit, the pertinent section will read as follows:

function is_altq_capable($int) {
   /* Per:
    * Only the following drivers have ALTQ support
   $capable = array("ae", "age", "alc", "ale", "an", "ath", "aue", "axe", "awi", "bce",
         "bfe", "bge", "bridge", "cas", "dc", "de", "ed", "em", "ep", "epair", "et", "fxp", "gem",
         "hme", "hn", "igb", "ipw", "iwi", "ixgbe", "jme", "le", "lem", "msk", "mxge", "my", "nfe",
         "nge", "npe", "nve", "ral", "re", "rl", "rum", "run", "bwn", "sf", "sge", "sis", "sk",
         "ste", "stge", "ti", "txp", "udav", "ural", "vge", "vmx", "vr", "vte", "wi", "xl",
         "ndis", "tun", "ovpns", "ovpnc", "vlan", "pppoe", "pptp", "ng",
         "l2tp", "ppp", "vtnet", "ue");

Hopefully this post will save other users some aggravation, as the information was not too easy to find.  I have tried to salt this post with enough search terms to lead an interested user to this solution.

IPsec / IPSEC on pfsense 2.2, MOBIKE=NO option?
« on: January 28, 2015, 10:07:49 pm »
I am wondering if it might be possible to add a toggle for the MOBIKE protocol in pfSense 2.2?

Under the current implementation, when IKE-V2 is used, MOBIKE causes traffic to cross UDP port 4500 whether or not NAT traversal is necessary.

The configuration parameter "mobike=no" keeps IPSEC traffic on UDP port 500.  It might be handy to add the toggle on the Phase 1 page in the NAT-T dropdown, and add a brief explanation of the function of the toggle.



I just upgraded an HP T5740/T5745 thin client from 64bit 2.1.5 nanobsd to 64bit 2.2 nanobsd, and the box now crashes at random after 10-30 minutes of uptime.  I had been running pfblocker, but that has now been completely removed, and the crashes persist.  The only special thing going on is a single IPSec tunnel.

The hardware is a single core Intel Atom N280 (single core HT), with a Broadcom based gigabit interface (bge), and a dual port Intel NIC (em) in the pcie expansion bay.

This setup was rock solid running 2.1.5 64bit nanobsd, uses little power, and maintains a CPU core temp around 24-26C.

I tried different powerd settings (adaptive, highdaptive, max), and crashes persist in 2.2.  All of the preventative tuning measures for BGE and EM cards are in place.

I put a monitor on the box, and the crash dump scrolls past too fast to read until it finally stops and reboots.

Any tips?

Pages: [1] 2