I decided to redo it all and start over.  (wipe and reload) Seems to work fine now.  No idea what was going on before.

Folks, could you please do a ps auxww | fgrep dns at the pfsense CLI prompt and check how many filterdns processes are running on your system ? TIA

That gets complicated quickly with single instance of dnsmasq. Your only choice is multiple dnsmasq instances and keep track of them.

this bug still exists in the latest nanobsd http://forum.pfsense.org/index.php/topic,52980.0.html

Ok…sorry to bother the forum with this issue....it's fixed now after 7 hours of messing around.  The problem resided in the use of Sabrenet NT-USB20 USB to Ethernet device on the WAN.  Weird that the device, when connected, was recognized and allowed me to set up the box.  I was able to get a DHCP connection and was able to ping through the device tp www.google.com and other but was not able to browse outside the LAN network with computers on the LAN.  The LAN card is a MB Nvidia. With NO changes to the rules or the Box other than swapping out the device to a StarTech USB/Ethernet dongle.  The dongle was setup as the ue0 device as ta-dah!  Success!  Am able to browse the internet from the LAN and access the webgui and sshd from the WAN.

seem to be fixed with this commit https://github.com/bsdperimeter/pfsense/commit/2ef160144f2232e89810023c63af99c2b476fe86

I still get it on my test box every now and then (maybe about every 2 or 3 days). The WAN of the test box sits on my LAN and gets DHCP from the production pfSense that is talking to the real internet. All my production systems on the real internet have static IPs, so I can't say if there is any intermittent issue when getting DHCP from an ISP in some way. I am in an area with mains power that goes on and off all the time (10 times a day), we have UPS with big battery banks, but I think that sometimes the transitions back and forth from mains <-> inverter cause glitches for some of our switches. So the test box WAN physical switch might "disappear" for a moment and come back. I'll try and induce it by power cycling its local switch.

@jimp: The IPsec status check is all in diag_ipsec.php I thought. What it was supposed to check was for the presence of both a p1 and matching p2. I suppose transport mode is just slightly different enough that the current checks don't let it line up. You're right. It's definitely the ipsec_phase2_status call in diag_ipsec.php that returns false, and the ipsec_phase2_status implementation in /etc/inc/ipsec.inc isn't matching the output from setkey. The two SPs I currently have looks like this: 77.105.xxx.yyy 24.23.xxx.yyy gre in ipsec esp/transport//require spid=36 seq=3 pid=22013 refcnt=1 24.23.xxx.yyy 77.105.xxx.yyy gre out ipsec esp/transport//require spid=35 seq=0 pid=22013 refcnt=1 (substitute gre for any if not using the "Cisco compatibility") There are no square brackets at all on the address line in transport mode, which definitely confuses the current code. The corresponding SAs looks like this: 24.23.xxx.yyy 77.105.xxx.yyy esp mode=any spi=1965845(0x001dff15) reqid=0(0x00000000) E: blowfish-cbc  zzzz A: hmac-sha256  zzzz seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Aug 27 15:32:04 2012 current: Aug 27 15:35:28 2012 diff: 204(s) hard: 3600(s) soft: 2880(s) last:                    hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3 pid=43976 refcnt=1 77.105.xxx.yyy 24.23.xxx.yyy esp mode=transport spi=173094859(0x0a5137cb) reqid=0(0x00000000) E: blowfish-cbc  zzzz A: hmac-sha256  zzzz seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Aug 27 15:32:04 2012 current: Aug 27 15:35:28 2012 diff: 204(s) hard: 3600(s) soft: 2880(s) last:                    hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=43976 refcnt=1 I'll dig into the ipsec.inc code some more to see if there could be an easy fix to allow the code to match the correct data for transport mode. /wj

Thanks!

This made it into the build: 2.1-BETA0 (i386) built on Sun Aug 26 20:04:49 EDT 2012 I just updated my test system and got output on the console like: Beginning package installation for blinkled . 100% Installing blinkled and its dependencies. 100% 100% 100% Note that the repeated 100% are because multiple files are downloaded. The details of every file name are not output to the console, so you see muliple sets of progress %age, one after the other.

Fixed! Thanks jimp!

That fixed my issue. Thanks!

your post made me look at the diff for the last update to filter.inc (the CARP related one), and indeed, it appears to cause the problem. The lines: if ($int != false and $int != $wan_interface) { 3169 3168 $ipnet = convert_ip_to_network_format($ip, $carp['netmask']); 3170 3169 if($int) 3171 3170 $lines .= "nat on {$int} inet from {$ipnet} to any -> ({$carp_int}) \n"; I changed "if($int)" to "if($int!='gif0')" and the error goes away. Now I realize this is an ugly hack, but I think it proves that there is an issue here. Will file a bug report.

Mine is http://ec.transcendusa.com/product/ItemDetail.asp?ItemID=TS1GDOM40V-S

Thank you for taking the time to investigate and patch. You guys are great!

Apparently the FreeBSD dhclient, that is used in pfSense, does not support that behavior. The ISC implementation does support it.

nevertheless - how can I deactivate the VLAN PCP patches in pfSense? I don't need them anyway.

I have a simular issue with my pfSense installation. I get the following errors in the system log: Aug 21 20:53:40 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:17: cannot define table [CLEANED]: Cannot allocate memory /tmp/rules.debug:19: cannot define table pfBlockerLevel1: Cannot allocate memory /tmp/rules.debug:21: cannot define table [CLEANED]: Cannot allocate memory pfctl: Syntax error in config file: pf rules not loaded' Aug 21 20:53:59 php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:17: cannot define table [CLEANED]: Cannot allocate memory /tmp/rules.debug:19: cannot define table pfBlockerLevel1: Cannot allocate memory /tmp/rules.debug:21: cannot define table [CLEANED]: Cannot allocate memory pfctl: Syntax error in config file: pf rules not loaded The line in question reads [17]: table <[CLEANED]> persist file "/var/db/aliastables/[CLEANED].txt" Aug 21 20:53:59 php: : There were error(s) loading the rules: /tmp/rules.debug:17: cannot define table [CLEANED]: Cannot allocate memory /tmp/rules.debug:19: cannot define table pfBlockerLevel1: Cannot allocate memory /tmp/rules.debug:21: cannot define table [CLEANED]: Cannot allocate memory pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [17]: table <[CLEANED]> persist file "/var/db/aliastables/[CLEANED].txt" I have replaced the names of the list with [CLEANED] :) When I look at the pfBlocker configuration it's not even activated and does not have any lists configured. I have had it activated with lists configured before but the package has been reinstalled since then. Even if I uninstall the package I get the log errors. It looks to me like there are some config left from the old installation. How can I clean up all old config? Thanks