Hi

Do you mind posting the working around you found?

Thanks.

Factory default will give you WAN and LAN.
Then login to web interface 192.168.1.1 from LAN, Interfaces->Assign, make OPT1, OPT2 on the required hardware ports.
Enable them in Interfaces->OPT1, OPT2 and give them IP addresses in other subnets.
Then you have to add firewall rules to each interface to allow whatever traffic you wish to come in from those interfaces.

Not sure what you mean/require when you say "ideally i'd like to have the OPT ports as backup" - they will have different subnets to LAN.

I use startssl for my pfSense certs.  The root is trusted by all major browsers.  I import the Class 1 intermediate cert into CAs and the issued certificate in Certificates then tell webConfigurator to use the issued cert.  It all just works.

I would delete what you have done then reinstall the end certificate pasting in JUST the issued cert, no CAs.

pfSense should automatically see that it was issued by the intermediate and see that the intermediate was issued by the root.

You should also be able to safely delete the root cert from pfSense.  If that is trusted by the end browser it's already and there's no reason to have it on pfSense.

Suricata should not be the cause of the error.  The file with the foreach() error is not a Suricata file.  It is a pfSense system file.  The error is happening in the section of code where the firewall is attempting to iterate over the configured firewall interfaces.

Have you made any other changes to the firewalls or to the host you are connecting from?

Bill

LDAP only supports password authentication.

Here's one two-factor solution that does:

https://www.duosecurity.com/docs/ldap

I've been using a free account to add two-factor to pfSense OpenVPN using RADIUS for a while now.  Works great.  Can't imagine LDAP would be any different.

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.