doing a search, I saw another instance where 3 didn't work and they speculated it had reached some max and converted to read only…. IDK

I'm aware of why not to do it.

I'm asking if it's intentional that it shows up in one view but not the other, when for the sake of those specific machines, those views are the same.  (The difference being showing inactive leases)

The code for all that is just PHP. It is all in GitHub at https://github.com/pfsense/pfsense and in your pfSense box (Diagnostics->Edit File). Copy the relevant files, edit them, save them on a system you can play with, get it working…

/usr/local/www/interfaces.php - has some stuff for entering directly PPTP/L2TP username password...
/usr/local/www/interfaces_ppps_edit.php - entering username password... for L2TP on PPP (I think that is what you want)

It sounds like you understand what is needed, so have a look at that code and you can add an extra field for the shared secret.

Then look in
/etc/inc/interfaces.inc function interface_ppps_configure($interface)

That writes the config file/s for that stuff.

Lines like:

set auth authname "{$ppp['username']}"

Put the parameters in the config file.
Add your new parameter there somewhere.

When it is working, make a pull request online in GitHub (just make the few edits in the GitHub webGUI is easy).

Then everyone in South Africa and elsewhere gets the benefit.

yes you will

many thanks for repling, I'll take a look.

Ideally I would like read only access, apart from allowing changes to one firewall host alliases, to add in people who need the penalty box - I guess this level of lock down isn't available yet ?

Is there anything that needs to be done?

Sorry, no idea.  I was just sharing my experience with what happened to me.

Removing all of the old certs is what helped, not the full reset, but the full reset removed them. After you access a few more pfSense installs it will break again until they fix the bug.

hahaha had this one today, so i did the following:

typed https://this.is.my.wall:443/system.php and changed theme to nervecenter.

hahaha had this one today, so i did the following:

typed https://this.is.my.wall:443/system.php and changed theme to nervecenter.

Not currently, no.

You can review the changes manually under Diagnostics > Backup/Restore on the Config History tab

Not without rewriting the code, I suspect.  There are other monitoring packages available that may give you what you want.  Look into bandwidthd, darkstat, ntop, ntopng for starters.

I found some code that may work see below:

<virtualhost *:80="">ServerName undesired.example.com   ServerAlias example.com notthis.example.com   Redirect / http://www.example.com/</virtualhost> <virtualhost *:80="">ServerName www.example.com</virtualhost>

I found this code on http://stackoverflow.com/questions/3028166/how-do-i-redirect-a-user-using-apache-rewrite-to-the-fully-qualified-domain-nam

My question before I attempt to add this is what web server does PfSense use 2.1.5 64 bit and what web server does 2.2 64 bit use?

I'm assuming that it is Apache but you know how the saying goes. I would like to see functionality built into PfSense in the form of a check box maybe on the Advance tab. If I have some time I may try to hack this in this weekend. Doesn't seem like to many lines of code to add.

Ok this worked as intended, but with a side effect, now I'm never redirected to https, the idea was to redirect only if the "sgerror" was on the url, but now I have to explicitly put https to go to https on my webconfiguration. This is better than nothing, but if it were only to url's with "sgerror" on the string it would be perfect.

Something wrong with my RegEx pattern?

Best Regards

Gotcha, thanks!

Would the format of the Snort/Suricata Alerts Tab be a reasonable Format to follow?

It wouldn't be too hard to mimic that layout for the States Table.

-rw-r–r--  1 root  _dhcp  867k Oct 22 14:16 dhcpd.leases
-rw-r--r--  1 dhcpd  _dhcp  2.4M Oct 22 14:04 dhcpd.leases~

I guess thats not that big, right ?

I found the delay was actually coming from the browser, not the pfSense box.  By removing the exceptions for the self signed certificates in the browser, and re-accepting them, all is good now and pfSense GUI is back to running fast.  I'll keep an eye on it and post if anything comes up.

This is an issue from Firefox 31 (I guess you were using Firefox). There are other threads about this also. In Options, Security you have to View Certificates and delete all the ones listed under "Company Name" - those are the "unknown" ones that you have previously added as exceptions in the past. Then things speed up again.