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.

Screenshot_20170523_171914.png
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.

"It's one of the default firewall behaviors: "security by obscurity". "

Blocking icmp would not fall to "security by obscurity"… Changing your ssh server to run on port 2222 would be an example that that.. Your still listening on ssh, just not on the standard port trying to hide.  Not allowing icmp would not be an attempt at obscurity.. Its something your not actively allowing

I guess if you think doing such a thing "hides" you from the internet you could class it as obscurity ;)  But default out of the box pfsense and pretty much every firewall out of the block all unsolicited inbound on any port or protocol.. So I wouldn't call it an attempt at obscurity ;)

Not possible in GUI. Check this thread it you are comfortable with editing mpd5_wan.conf. https://forum.pfsense.org/index.php?topic=47296.0

2 years is long enough for me to but new hardware.

Thanks for your replies.

On the gateway advanced settings you could try making the Probe Interval and Alert Interval longer. That should make it take more time to get a few responses and decide that the gateway is up.

If it is flapping like that so often, then you really need to get it fixed (I'm sure you know that!). And while waiting for some repair action, you can just take the WAN gateway out of the gateway group. You should still be able to look at gateway status for it, and when you think it seems happier, try putting it back in the gateway group.

@gjaltemba:

I would keep the default gateway on opt1 by disabling firewall rule. Just the NAT rule is not enough info by itself. Move it to the top.

this seems to have worked.

thank you

pfSense seems to have a 20min arp cache and most client systems are about 60 seconds. If you think the issue is the arp cache, just wait 20 minutes. If the problem doesn't resolve after 20min, then it's not the arp cache.

^yup!! The management has to be untagged - this has been a big complaint from many people..  So you can run a SSID with no tag if you want that on the same layer 2 as your management network.  Or all of your ssids can be on different vlans, either static or you can set them dynamic as well.

So my controller and AP are on my wlan 20 vlan, so on the trunk port connected to my AP vlan 20 is the pvid and is untagged.  This is the same network as my eap-tls authed ssid.  Then the other 3 ssids are for iot devices, guests and stuff that can not do eap-tls..  these 3 vlans are tagged.

@gjaltemba:

Glad you got it working.

Firewall->Aliases is not hard to find.

Thanks for the help!