thanks jimp, Will do this in the future. Makes sense. Barry

Thx man i've got it working.

In general this should work without problems. Further if it does not work you can connect to pfsense using ssh or console and reassign the LAN ip address. then it will ask you if you would like to revert to http. This should be enough. I did this on pfsense 2.0.0 and it worked.

Same problem here, i was testing ldap authentication with a Windows 2008R2 Domain Controller and had the test-dc shut down: i was barely able to login to the system. I suppose it's due to the fact that almost every page you visit the system checks if the user is ok. According to http://doc.pfsense.org/index.php/User_Manager "If you are using an LDAP server and the authentication server times out, the system will fall back to using pfSense's built-in authentication" so I think this could be solved lowering the ldap timeout but i havent found an option for it. Generally I think this should be changed: the ldap user connection could be used for authenticating VPN users but having the ldap server down shouldnt be disruptive for the whole firewall system. EDIT according to system log, it looks like everytime the system try to check which group the user belongs to: php: /system.php: ERROR! ldap_get_groups() could not bind to server test 2008.

Reloading the widget faster would put too much of a burden on the lighttpd process on small devices. If you really want realtime, login over ssh and watch with top -SH

IE is crap, use FF, Chrome, Safari, Opera. Basically any sane browser works. IE is not sane. That said, it's something that has already been fixed. I think it was this commit: https://github.com/bsdperimeter/pfsense/commit/6478e71e95c3224cf2b83d7e3e8f715c6a61f31e

The way to give it a good swift kick is to do: killall -9 php; killall -9 lighttpd; /etc/rc.restart_webgui

Thank you very much !!.

Hi! Thanks for the reply! I will try to install Munin. Seems very promising. Are you displaying the Munin graphs from your router or another external webserver? Since i'm a FreeBSD newbie, do you have any good site for basic commands in FreeBSD? (Like editing a config file and such)

There is an option with wget without using scp. http://doc.pfsense.org/index.php/Remote_Config_Backup @namezero111111: Afaik, there is a backup package that does exactly that. It needs a subscription however, but I would assume that it is safe. A lot of companies (like mine) probably would have a problem though having their firewall configs backed up in a cloud It encrypts the config before uploading, so we strictly store encrypted blobs, we have no readable configs. It's as safe as your encryption key is strong, plus requiring another account just to get to your encrypted configs.

With optimal firewall rules, that should be as simple as one click to disable that particular rule. Or if it's more complex than that to the extent you can't pass the traffic easily with a single rule, have a block rule at the top that you enable for maintenance, leave disabled normally.

Thanks for the replies.  Now that I understand things a bit better I agree that hiding those tabs for assigned interfaces would not be a good idea.  I commented on Efonne's ticket and added screenshots for a sample configuration that would benefit from the improvement.

Made some further optimizations and fixed the license up: https://github.com/bsdperimeter/pfsense/commit/c91e242e607c6ff2376350108255dbadcdb039e0

Just checked and the deletion case was ok but not rename. https://github.com/bsdperimeter/pfsense/commit/bb83746870f64525e477e1ddd14adc56b894b758 Easy fix. Would also fix itself on reboot when the users are cleaned up and resynced. For a quicker fix that doesn't require editing and files, go to Diagnostics > Command and run this in the PHP exec box: require_once("auth.inc"); local_sync_accounts();

@pffan: Gah! What we have here is an instance of browsers behaving badly.  I didn't realize what the problems was at the start because both IE and Firefox demonstrated the same behavior.  Once I tried Chrome however, everything worked as expected.  I think that because I had previously connected to the webGUI on http port 80 with both my browsers before, it kept pulling the cached page on my subsequent attempts and this is what was causing the redirect to https custom port.  Once I cleared the history and cache, everything is working as expected. Hopefully someone else can benefit from this information. I did, I run into same problem, thanks.

@phil.davis: I am using Firefox11 on Windows7. It works fine for me uploading to a nanobsd system, on 2.0.1 and 2.1. After browsing to the file then pressing upload the top of the display says: Uploaded file to /tmp/filename and executing "ls -l /tmp/filename" lists the file as expected. So there must be something else special about your environment. I'm seeing some problems for sure, I guess that Squid f*cked more stuff up somehow perhaps then.. This was a freshly installed box though, actually only the various Squid packages have been added and messed with. I guess I'll do a reinstall soon if things don't start to work as expected.

Registered as Bug #2326.