Use the port 465 and it works :)

@jimp:

Should work fine. Once we post images for 2.0.1 they are sized to 1000's instead of 1024 so they'll fit again.

Okay, that sound's nice. I will change the image until 2.0.1 will be released. its working like a charm right now :-)

Hi !

@packets:

…. Maybe this is a bug on RC.

Maybe it's time to shift to Release  ;)

@jimp:

It's been fixed in the repo already.

Code is available on github.

Thanks for the fast reply.
I was pretty sure that the missing ? was fixed already, I just couldn't find my way to  github.

Not sure anyone is actively working on that. someone on the forum had some graphing working. not sure anyone submitted patches.

Looked once, didn't find it. Found it the second time… Thanks :)
(For anyone else: http://doc.pfsense.org/index.php/Remote_Config_Backup )

thanks for the reply jimp  ;D

Good news then :-)

If you set nonstandard port while using https, then you should use that same port, but you'll need to use http

and as marcelloc said assigning interfaces on console is the key to revert gui to http

You are correct of course, that would be the best way to do it.
(in my defense, I wrote the first post at 3:00am local time  ;D )

you have to create local users/groups that match the users you want to use. The passwords from LDAP are used for authentication, but the permissions must still be managed inside of pfSense.

There is a ticket open (I think for LDAP… might be RADIUS) for passing group info back and forth to make it easier in the future but it's not all there yet.

You may have set "Max Processes" under System > Advanced, it grows exponentially as it increases the number of GUI processes and allowed PHP children. If you put in >10, you'd end up with >100 PHP processes.

You'll need something like this:

http://doc.pfsense.org/index.php/Remote_Config_Backup#Pulling_on_2.0

I fixed the issue, there was a weird character in the drivedb.h file on line 263 and removed it.

Weird?

@marcelloc

Thanks for the info

I got this in systemlog:

Oct 10 20:57:46 php: /index.php: Successful webConfigurator login for user 'admin' from 10.0.0.6 Oct 10 20:57:46 php: /index.php: Successful webConfigurator login for user 'admin' from 10.0.0.6 Oct 10 20:57:15 php: /index.php: User logged out for user 'admin' from: 10.0.0.6

I think that's all you need, isn't it ?

If you put in a really broken static route, like one for a locally connected subnet you're on, and you remove it, it'll break connectivity for the subnet you had the broken route on. Easiest way to fix that is just reboot.

I'm trying to setup WebGUI access on the WAN (temporarily for testing purposes). I can't figure out why my custom port doesn't work. If I leave custom port blank and create a rule under the WAN tab to forward to the HTTPS port I can access the WebGUI from an external computer. However, when I set a custom port and change the WAN rule accordingly it just times out when I try to connect.

Works:

Does not work: