If you want to block certain access to the webGUI then you're thinking about security, right. Start with using HTTPS for pfSense administration and use a non standard port like :456. Block access to it from W-LAN and it won't affect regular web usage.

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

Not very elegant solutions but here is what I do whenever I don't have a choice other than IE Left click and hold (i.e. don't release the left mouse button) on the main menu item, move the pointer down the menu selections (as if you were trying to drag the main menu item) and then release the mouse button. Now the drop list should stick and you should be able to make a selection by clicking on it. Right click on the main menu. Move the pointer to the droplist area and hit the escape key or simply click on the selection if you can partially see it. Left click main menu then move the cursur swiftly from the main menu item over to the drop list.

No.  1.2 is frozen.  It will appear in 1.3.

I was looking for the same solution for some time. I think rsyncing or SCP-ing them every 5 min is the best. In 1.3 I thought this would be a feature.

Are you sure you locked yourself out? Because there is an anti-lockout in place. If you didn't deactivate it… And if you did deactivate it i'm sure you did read the note right next to the checkbox: Disable webGUI anti-lockout rule By default, access to the webGUI on the LAN interface is always permitted, regardless of the user-defined filter rule set. Enable this feature to control webGUI access (make sure to have a filter rule in place that allows you in, or you will lock yourself out!). Hint: the "set LAN IP address" option in the console menu resets this setting as well.

Well the reports are that when you enable this option load balancing fails altogether.  I suppose you could open up system_advanced.php and take out the code that looks for PPPoE and try enabling it yourself to see the results.

This is why is says "WARNING! Cannot be deinstalled." It is due to the dash replacing index.php but when you upgrade the original index.php is in the package and is therefore the dash one is replaced. You then need to remove the dash to make the package system happy to reinstall it BUT this removes all the widgets that were in the package (but not ones that you have added). I can't quite work out why you have to visit the index page to make it restore the dash. I guess when you uninstall it restores the index.php from somewhere and you get a broken dash back. I guess visiting it resets some values on the load. ??? The install restores the widgets and reinstalls the dash version of index.php I never raised this as a bug as this will all go away once the dash becomes the default (in 1.3)

@morbus: I must say I find it useful when managing multiple pfsenses (eg CARP) to glance at the list of tabs page titles to find the right one rather than having to flick through each one to find stuff Understandable. We are most likely going to make the actual window/tab title show the hostname, but not show it where we just removed it. So basically it will be shown in the upper right hand corner, and as the window title

@cmb: At a glance it doesn't look like anything but log noise. Hot plug events on static IP interfaces don't do anything, so there isn't anything for it to be doing wrong.  :)  I'll check into it though. are you actually seeing a problem? If so, what specifically is it? My WAN access in unavailable because of the problem. Fortunately I have a backup WAN access and the Load Balancer works and directs all the traffic to the backup line. How would I get the WAN to work? Already tried a new ADSL modem, but that didn't help.

You should be fine restoring the 1.0.1 config to 1.2, and leaving the secondary on 1.0.1 for a brief period should be fine as well.  I would recommend disabling the configuration sync until they're both on the same version, I'm not sure if that would work right or not.

Ha, nice! Useful for the backup firewall, so I see the difference :-)

Yep your code works for me in IE7 and Firefox. Cheers

@jahonix: And if you look here: http://snapshots.pfsense.org/FreeBSD6/RELENG_1_2/updates/ you'll find 1.3 builds and NO warnings! Uh oh - thanks jahonix, I removed those. They should have never been there. knakkergaard: I think you must still be trying 1.3. The 1.2RC3 images from here are what you want: http://snapshots.pfsense.org/FreeBSD6/RELENG_1_2/updates/ though at this point, you probably need to reinstall with: http://snapshots.pfsense.org/FreeBSD6/RELENG_1_2/iso/

Ditto that, 1.0.1 has a lot of bugs, 1.2RC3 has no known ones. The official RC3 release will be out tonight, but it'll be the same as what you find here now: http://snapshots.pfsense.org/FreeBSD6/RELENG_1_2/

@GruensFroeschli: You did configure it once didnt you??? anyways. services – dhcp server --> "LAN-tab" --> go to the bottom and add the MAC. yea i did configure it and that's what i was looking for thank you very much topic marked as solved, thank u guys

Moving that line does un-break the page, but the line was printed because of some debugging code I removed that shouldn't have been there. Fixed. Thanks for the report!

This was fixed in snapshots within the past day or so. Please try a new snapshot and report back.

Ok, that was my understanding also. The point is that adding a static route has an interface on it which seems to be redundant. It doesnt matter which interface is chosen, does it?

It's not required, but passing your credentials over the Internet in clear text is NOT a good idea.