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.

it was some leftover probably..

Please file a bug report at cvstrac.pfsense.com .. Thanks!

@cmb:

if polling fixes the problem, you know it was interrupt related.

It didn't solve. I will change second eth wich is Netgear GIGA card for 10/100 Intel and try then.
My be this reltek based card is buggy when VLAN's are involved.

Sasa

n/m

I had to check webGui as HTTPS in the setup page, it works now :D

Can I have it so that when im on LAN i can just HTTP and when im accessing remotely i do HTTPS?