Thanks for the info! I will try this first thing tomorrow-

General For things that do not fit into one of the more specific categories below.

I bought a T-shirt and Polo.  Pretty cheap all things considered.

Thank you :)

OK, it seems like getting what you want requires some "hacking" and additional stuff installed. While this can be great stuff and huge success when finally getting it to work, keeping the systems updated and patched (and patchable!) with these hacks will most likely be a pain in the ass in the long run. The extra hour spent on "manual identity management" (which you can document thoroughly by spending another hour on it) may well be worth it in the end.

Just an FYI for the future. A S.M.A.R.T test is just that. A Quick Smart scan of the hard drive. It checks general and most known hard drive failure causes. But not all of them. If you suspect a hard drive of issues, it's always best to remove it from whatever unit it is in and perform a full diag using tools that can perform deep scans for issues. This will tell you for sure if it is the hard drive are not. I've had Smart tests pass where deep scans will show corruptions in the disk. There are tons of free tools that can do the job. I personally use LifeGuard by Western Digital.

"log :587." I find it highly unlikely that spam would be using port 587.. Unless the user was sending it on purpose through a smart host and authing to the smart host as well.  This would not be tracked back to your IP.

The export package is not intended to be used by end-users. There is no way for a user to login and download just their own client.

How to config? Via webGui on http:// with port 80 or https:// with port 443. Unless you changed that. What is not working?

if you want great granular view pftop or pflowd.  You can find many free netflow collectors.  This captures everything.  I suggest at least trying it and you will understand.

Possibly a script that monitors the config file or a portion and if it changes it sends an email though this would not be managed in the gui.  It would most likely be managed by a cronjob.  If serious about this I can put you in touch with someone who has done some amazing scripting for me.  Be aware that he would not be able to guarantee it would work after upgrades and would have to be redone in the event of redeployment. Probably best to get the whole config and use a diff tool to show you the difference in the configs.  This way you can restore the whole thing if you want.

@jimp: When you do "make package" for a freebsd port, it puts a .txz package file in the port's work dir. That's what you copy over. That and the package files for any dependencies. And of course it will affect pfSense. You could break it in any number of ways, which is why we don't put those things on the firewall. Oh ok. Thanks for that info. Might as well leave it as it is.

OK, I understand. Thanks for feedback!!! César

Hi Folks, I am currently working with the same problem on pfsense 2.3.4 connecting with openLDAP with rfc 2307 scheme. Looks like I have used correct settings, I have attached my screenshot. But users get access any way if user present in group as memberUid or not. From pcap it is clear that LDAP returns for group parsing that found 0 matches. But user could get access to openVPN. [image: Screenshot_20170523_171914.png] [image: Screenshot_20170523_171914.png_thumb] OpenLDAP.pcapng

That your using a webhost that still uses ftp… I would check, any decent webhost will support sftp..  ftp really does need to die ;)  Users of services that do not complain that current more secure methods of file transfer are not available is the only thing that keeps it up and running. Shoot I was complaining to my host that they didn't support chacha20 on their ssh/sftp ;)  If all they had was ftp, I wouldn't be using them that is for sure..

Do you think creating rules for the LAN interface is a sensible thing to do ? Or is it just too much for a home setup ? Doesn't leaving the Anti lockout rule intact rules out the chances of locking my self out ? True, the anti-lockout rule specifically just allows access to ports 80,443,22 on LAN address. So having that always at the top will get you in from LAN. So you could put a block rule on LAN straight after that: block source any, protocol any, destination "WAN address" or even: pass source any, protocol any, destination "LAN address", ports DNS... block source any, protocol any, destination "this firewall" "this firewall" gets turned into a list of all firewall interfaces. So that would cover WAN, LAN (and you get in there first by the anti-lockout rule and give users access to DNS… by a rule before it) and any future WAN2, OPT1 etc that might exist now or be added. For the webUI (80,443) and ssh (22) you do not really gain anything because it does not really matter if someone starts from LAN and goes to LAN address or WAN address to access - they are connecting to the same service. But it does protect against them accessing any other services on any interface that might be enabled/listening. Whether it is overkill for a home setup is a matter of if you like tinkering around.