Easily fixed


Clarcnova : as soon as my new AP arrives, i'll let you know if it works or not!

Server's been back up since last night, you should be fine at http://snapshots.pfsense.org now.

Thanks, that worked. I'll follow the other thread.

Upgrading to 2.0-RC1 (i386) built on Mon Feb 14 02:12:45 EST 2011 seems to have addressed the issue.  Thanks!

As an aside (mostly just to make me feel better), the issue of \ vs / in the monitor likely popped up when I deleted and re-created all of the load balancer entries after moving to the i386 platform.  There's no real debugging value in this information other than to say that my brain fade happened after the migration, and that the original config was probably valid (and that's why it worked).

Cheers.

Well the way packages are reinstalled now, the key libraries are backed up before the packages are reinstalled, and restored afterward.

I haven't seen anyone who would reproduce it 100% every time with the current code.

That's great, so I can recreate the shaper without the need of changing all the rules first..
Thank you!

:o ok now i install a full version of pfsense on a hd and then mount it on my alix

thanks for reply

I think in /etc/rc it only mounts / and /cf explicitly, not all mountpoints in fstab.

wtf?

So this is maybe the reason why only / is mounted, when a filesystem-check (due to maintainance or not properly dismounted disks) occurs? I have had an installation with /var and /home on separate slices, but only problems due to the not mounted filesystems. I switched that out by having only one slice, but I'm not really glad with this situation, so a stock freeBSD on EVERY boot mounts ALL filesystems!

It would be nice to change that behaviour please! I want back my different slices!

Wait for the next new snapshot, update, and try again. That should be fixed, but there hasn't been a new snapshot uploaded in the last couple days because of things getting shuffled around with the snapshot server/builders.

Check for ESP traffic on your WAN interface using this command (replace pppoe0 with your interface):

tcpdump -i pppoe0 -n esp

you should see something like this:

then check for traffic on LAN interface by specifying host you are trying to reach:

tcpdump -i vr0 -n host 192.168.100.254

Ask and ye shall receive…

http://doc.pfsense.org/index.php/Importing_OpenVPN_DH_Parameters

I made some commits today to handle this better. I added a 5 second timeout to the connection so it should fail gracefully in a short time. If you are on a snap from the last couple days, you can just update via gitsync until the snapshot server comes back:
http://doc.pfsense.org/index.php/Updating_pfSense_code_between_snapshots

@GrandmasterB:

@salvor:

I installed "2.0-BETA5 (amd64) built on Sun Feb 6 07:01:51 EST 2011" as guest in vmware player 3.1.3 with Windows 7 x64 host.

/var/IS_VMWARE exists

/etc/sysctl.conf contains  kern.timecounter.hardware=i8254

/boot/loader.conf contains kern.hz="100"

You might want to mention the exact version you installed. Just cut/paste from Status->Dashboard page.

Please read carefully.
After install everything indeed is OK, as i mentioned in my first post. But when you do an upgrade after the first install, the sysctl.conf option is gone.
Please try that.

Sorry I misunderstood what you meant by upgrade (I thought you replaced 1.2.3 with 2.0-BETA5.)

I remember after updating to Feb 5 version from Feb 2 version, the console would get stuck before showing the menu.  And rebooting with extra logging enabled showed t_delta too long and t_delta too short messages.  Installing from scratch made the console get unstuck.  Maybe this is related?  I was going to try updating to see if I could reproduce your problem, but the snapshot server is down.

Hi,

Well, this is not a bug, this is a "limitation". See http://redmine.pfsense.org/issues/1083 for details !

Pierre

Hi jon,

I don't have paid support,  but i don't understand ths problem, with linux, shorewall, and ip_conntrack_ftp (kernel module) all workiing "out of the box".

Sorry for pfsense team i think it's not your fault but kernel freebsd problem.?

Now I am again in the office and the pfsense shows me till yesterday after the update

"```
Packages are currently being reinstalled in the background.

Do not make changes in the GUI until this is complete.

Systemlog shows this:

Feb 12 08:43:28 php: /index.php: Successful webConfigurator login for user 'admin' from 172.17.0.100
Feb 12 08:43:28 php: /index.php: Successful webConfigurator login for user 'admin' from 172.17.0.100
Feb 12 08:43:23 sshlockout[61009]: sshlockout/webConfigurator v3.0 starting up
Feb 12 08:43:23 php: /index.php: webConfigurator authentication error for 'admin' from 172.17.0.100
Feb 12 08:43:23 php: /index.php: webConfigurator authentication error for 'admin' from 172.17.0.100
Feb 11 15:22:23 php: /index.php: User logged out for user 'admin' from: 172.17.0.100
Feb 11 15:17:45 check_reload_status: reloading filter
Feb 11 15:17:45 check_reload_status: syncing firewall
Feb 11 15:17:26 check_reload_status: syncing firewall
Feb 11 15:17:25 php: /pkg_mgr_install.php: Beginning package installation for OpenVPN Client Export Utility.
Feb 11 15:17:24 check_reload_status: syncing firewall
Feb 11 15:17:23 check_reload_status: syncing firewall
Feb 11 15:17:22 check_reload_status: syncing firewall
Feb 11 15:17:22 php: : WARNING! Configuration written on bootup. This can cause stray openvpn and load balancing items in config.xml
Feb 11 15:17:20 check_reload_status: syncing firewall
Feb 11 15:17:16 php: : Creating rrd update script
Feb 11 15:17:11 dnsmasq[51734]: read /etc/hosts - 2 addresses
Feb 11 15:17:11 dnsmasq[51734]: read /etc/hosts - 2 addresses
Feb 11 15:17:10 check_reload_status: updating all dyndns
Feb 11 15:17:10 dnsmasq[51734]: ignoring nameserver 172.16.0.1 - local interface
Feb 11 15:17:10 dnsmasq[51734]: ignoring nameserver 172.16.0.1 - local interface
Feb 11 15:17:10 dnsmasq[51734]: using nameserver 8.8.8.8#53
Feb 11 15:17:10 dnsmasq[51734]: using nameserver 8.8.4.4#53
Feb 11 15:17:10 dnsmasq[51734]: reading /etc/resolv.conf
Feb 11 15:17:10 dnsmasq[51734]: compile time options: IPv6 GNU-getopt no-DBus I18N DHCP TFTP
Feb 11 15:17:10 dnsmasq[51734]: started, version 2.55 cachesize 10000
Feb 11 15:17:10 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 11 15:17:10 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 11 15:17:10 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 11 15:17:10 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Feb 11 15:17:10 dhcpd: All rights reserved.
Feb 11 15:17:10 dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Feb 11 15:17:10 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Feb 11 15:17:10 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 11 15:17:09 php: : ROUTING: change default route to 192.168.1.1
Feb 11 15:17:08 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:08 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:08 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:07 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:07 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:07 php: : Gateways status could not be determined, considering all as up/active.
Feb 11 15:17:07 check_reload_status: reloading filter
Feb 11 15:17:07 apinger: Starting Alarm Pinger, apinger(11040)
Feb 11 15:17:06 check_reload_status: reloading filter
Feb 11 15:17:06 php: : Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.2.1
Feb 11 15:17:06 php: : Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.1.1
Feb 11 15:17:06 php: : ROUTING: change default route to 192.168.1.1
Feb 11 15:17:06 php: : Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.2.1
Feb 11 15:17:06 php: : Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.1.1
Feb 11 15:17:05 apinger: Exiting on signal 15.

After a reboot it seems to be fine. Syslog shows this:

Feb 12 08:49:09 sshlockout[53793]: sshlockout/webConfigurator v3.0 starting up
Feb 12 08:49:09 login: login on ttyv0 as root
Feb 12 08:49:07 root: /usr/local/etc/rc.d/svscan.sh: WARNING: /var/run/service is not a directory.
Feb 12 08:49:07 php: : Resyncing configuration for all packages.
Feb 12 08:49:07 php: : Creating rrd update script
Feb 12 08:49:01 dnsmasq[58207]: read /etc/hosts - 2 addresses
Feb 12 08:49:01 dnsmasq[58207]: read /etc/hosts - 2 addresses
Feb 12 08:49:01 check_reload_status: updating all dyndns
Feb 12 08:49:01 dnsmasq[58207]: ignoring nameserver 172.16.0.1 - local interface
Feb 12 08:49:01 dnsmasq[58207]: ignoring nameserver 172.16.0.1 - local interface
Feb 12 08:49:01 dnsmasq[58207]: using nameserver 8.8.8.8#53
Feb 12 08:49:01 dnsmasq[58207]: using nameserver 8.8.4.4#53
Feb 12 08:49:01 dnsmasq[58207]: reading /etc/resolv.conf
Feb 12 08:49:01 dnsmasq[58207]: compile time options: IPv6 GNU-getopt no-DBus I18N DHCP TFTP
Feb 12 08:49:01 dnsmasq[58207]: started, version 2.55 cachesize 10000
Feb 12 08:49:01 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 12 08:49:01 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 12 08:49:01 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 12 08:49:01 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Feb 12 08:49:01 dhcpd: All rights reserved.
Feb 12 08:49:01 dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Feb 12 08:49:01 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Feb 12 08:49:01 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Feb 12 08:49:00 php: : ROUTING: change default route to 192.168.1.1
Feb 12 08:49:00 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:49:00 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:49:00 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:48:59 check_reload_status: reloading filter
Feb 12 08:48:58 apinger: Starting Alarm Pinger, apinger(24652)
Feb 12 08:48:58 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:48:58 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:48:58 php: : Gateways status could not be determined, considering all as up/active.
Feb 12 08:48:58 apinger: Exiting on signal 15.

http://forum.pfsense.org/index.php/topic,33228.0.html

Hi, Ermal,

Thanks for the quick reply. That makes sense. The only strange thing (and I guess I didn't make this clear in my post) is that as far as I can tell, both gateways WAN and OPT1 are functioning; indeed, they are the two outgoing connections I use, and are definitely passing traffic, even as php is identifying them as invalid/unknown.

However, as I said, it doen't seem to actually be causing a problem; so I'll just ignore for now.

Thanks again for all you are doing to make this project great.

Dave

Odd, initially I was getting denied a connection because traffic for OpenVPN (on the default port) was Denied by Default Rule, so I deleted it and recreated the rule and now it works (was using UDP and everything right, but log showed the connection being denied based on default deny rule).

Anyway, once I got the connection working, I tried to connect with a user from the "openvpn" group I created. I got an authentication error again, so renamed the group to "usersopenvpn" and saved it (it has no permissions assigned) and now the user can login to OpenVPN. So something was "stuck" both in the firewall rules and the group (I reset states before trying any of this), but now it's working. Can't explain it, if I see it again I'll report more details. This is all on a second firewall from the one I originally submitted about, that was having the same problem. I'll check the original one soon and see if I can get repeat results with SSL/user auth.