Addition: I have 2 tunnels, tunnel A and tunnel B. Tunnel A is a mobile tunnel, tunnel B is a static tunnel. In the IPSEC-log the description is always wrong! All entries refer as "tunnel A", even if that tunnel is a mobile tunnel and not connected or connecting! Every entry is from tunnel B, which is the static tunnel! If then tunnel A rises, same entries, this time right: tunnel A. But never appears any tunnel B entry in the logs. I then changed the tunnels in the config and now tunnel A is the static tunnel, entries appear as tunnel A. When tunnel B rises, entries in the log show tunnel B, which is right now. Is the way how the log-entries are generated different when a tunnel is mobile or static?

That worked great!

Same problem and the log shows Feb 11 07:54:39 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queuedrops.rrd -t :wan:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' Feb 11 07:54:38 php: : The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/wan-queues.rrd -t :wan:qACK:qDefault:qP2P:qOthersHigh:qOthersLow N:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: unknown DS name ''' But these are the only queues I can see in status:queues Andrew

@spoutin: sorry for the delayed response, i tested on the newest load and its working now. What was the issue. Thanks. mbuf tag patch was causing issues, it's been postponed to a future release.

It's normal with that theme, if you look close you'll notice that the "dead space" extends over from the bottom of the logo on the left, where the "faded" part stops. I'm not sure anything can effectively be done to fix that and keep the logo looking that way.

The mbuf tagging patch was backed out yesterday. That's probably what was causing the panic you had.

@ermal: You can rm -r /var/lock/* and it will start. Thanks for the quick reply. I don't have a /var/lock/ folder on my box. I created one to see if that would make a difference, it didn't. Anything else I could try? Edit: Thanks for pointing me into the right direction. Like I said, I didn't have a /var/lock/ folder but I found a /var/spool/lock/ folder. With-in that folder was a file named 'LCK..cuaU0.0' Deleted that file and now 3G is back into action!

@cconk01: Even though I cant access the web gui now, im pretty sure a reboot will resolve my issues… I just want to collect any information I can for you before I reboot.... Why do you believe a reboot will resolve your issues? Have you been modifying things before this problem came up? Did you modify firewall rules then the web access died? Your firewall log clearly shows a https connection attempt blocked on input on em1 (LAN?) How do you think a reboot will get rid of that rule? Perhaps you are planning to reset to factory defaults on the console when you reboot.

Thank you, I will try this tomorrow.

Hi, JMP, Thanks for the speedy reply! I really appreciate all the help you give here! So, I looked at my system routing table, and indeed, the default route is set to the WAN gateway, as you said. Is it possible to use gateway groups in the routing table of the router itself? The issue at hand here is I would like to be able to access my network via openvpn, even (perhaps especially) during failover mode when the main link is down. However, the router needs to be able to open a connection to the computer requesting an openvpn connection, and I get an error saying 'no route to host xx.xx.xx.xx' thrown by open vpn during the openvpn handshake process. So, if I could talk the router into using the gateway group instead of the default route, it would know how to route traffic out even when the WAN is down. There are a number of gateways that I see in the routing table (link#1, link#2…link#9) that I don't know the origin of; how they are defined, and how they do routing. Perhaps this is where I would look to send router traffic into the gateway group? I believe my fundamental confusion here comes from not knowing where the distinction lies between typical routing done by the routing table and the pf system that does the bulk in and out routing that pfsense is so good at. Any help understanding this would be greatly appreciated. Thanks so much, Dave

Anybody please upgrade to a snapshot of Feb 9 and after and just create a floating rule with direction out and a gateway pool and activate AON with source put to any.

Didn't even knew that existed. Thanks! Will serve its purpose!

Thanks for the update Jim

It should work fine - if it doesn't, let us know, and if possible, provide your configuration file so we can fix any bugs. Upgrading is supposed to be as seamless as possible (that's what we aim for) but unless people give us copies of their configurations (before and after upgrade) when they have a problem, it's hard to track down a fix.

Layer 8?? I didn't know they added a new Layer! When did this happen? NEVER-MIND!  :-[ [url=http://thecoffeedesk.com/news/index.php/2009/04/11/osi-model-layer-8/]http://thecoffeedesk.com/news/index.php/2009/04/11/osi-model-layer-8/

You are perfectly right, vlan tagging is not supported on my ath0 wifi card. In fact, I want to use a bridge on the lan interface to tag the wifi traffic. I have managed to make it work on pF 1.2.3 but I have some trouble with pF 2. I will test further today.

Well, don't I feel like an idiot now. Seems all is working now, thank you.

Looks like this is a known issue read http://redmine.pfsense.org/issues/935. Hopefully it will be fixed in time for the beta release. Thanks,