Did you create a rule on WAN that allows access to the webgui?

Yes, may be… but on for wan interface ?

Lan and OPT1 interfaces reports correct values and data directions...

Yes, i can duplicate this, you can open a bug ticket for this and 1.3 if you want, i think for 1.2 it is really cosmetic…, you can make a new config.xml with copy and paste various sections to a new one.....
grreetings
heiko

seems to be correct. http://cvstrac.pfsense.com/tktview?tn=1655
No time to test today.
Some news when i will reinstall (for the third time)

pfSense is not compatible with the m0n0wall-cmi but the m0n0wall-cmi could be extended/modified to manage pfSenses with it as well. Maybe try to convince the m0n0wall-cmi guys to dive into this or post a bounty like you already suggested.

for me i can print the firewall-rules with firefox 2.0 without problems…..

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/