Yeah I have a lot of devices too.. 65,000 of them? Here is the thing a mask of /16 is fine for a firewall rule where you have downstream network, etc.. It's great when you want to summary route over a vpn, etc.

It makes zero sense to be a mask on an interface. Zero!! lets say you had 1000's wifi device.. Ok use a /22, hey go nuts use a /21.. All that a /16 says is the person running this router/firewall/network doesn't understand basic concepts..

Making the mask so large is only going to cause you grief, overlap when connecting to other networks!! Is the big one... Extra overhead in your dhcp pool from a memory standpoint, etc..

You also run into problem describing your problems - because people assume /24 and when they see you say that x.x.100 talks to x.x.1 without routing it seems odd.. If your going to be posting networks that are off the norm, ie outside of a /24 then you should clearly post your mask when you give your networks..

Maybe its just the thing that blows my skirt up, gives me a draft around my balls I don't like - whatever it is to be 100% honest.. When I see someone posting that they are using a /16 - first thing that comes to mind is ok.. Your dealing with someone that doesn't get it - use small words and post lots of pictures. Do you get my drift? ;)

Thank you, jwj and John,for your answers and time.
John, your insight on the inner workings was incredibly useful.

I have set NxFilter on other VM inside the LAN created by PfSense. You can leave the DNS Resolver of PFSense and set an upstream DNS for NxFilter
Just give a rule on PFSense to allow connections on port 53 for the new VM.

Thanks for all of the suggestions - I looked at the mac addresses attached to all of the switches yesterday and didn't find the culprit. It is intermittent -- it happened to two users late last week and then again yesterday. (and I am pretty sure it happened twice before that - but wasn't recognized for the problem it is) I suspect it is some portable device that someone brings to the office and plugs in for a period of time. As long as nothing requests a new address things keep working. Hopefully the next time it happens I'll be in the area and can do some packet captures for some additional information.

@thejessicaduke said in OpenDNS and Captive portal:

BUT my dynamic DNS is enabled with Opendns service running on it.

You mean : a lcoal service checks your WAN IP, and update changes at your account at OpenDNS. That ok.
I'm doing the same thing, even if I'm not using OpenDNS :

0_1534858257252_548456b7-452a-4161-a473-1ccecd76c665-image.png

Check out : https://www.netgate.com/docs/pfsense/captiveportal/captive-portal-troubleshooting.html - most issues are mentioned.
Know that one someone says : my captive portal doesn't wrk, it's ost of the time a faulty DNS setup.

Strange indeed :

[2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: dig @192.168.1.1 google.co.uk ; <<>> DiG 9.11.2-P1 <<>> @192.168.1.1 google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60086 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.co.uk. IN A ;; ANSWER SECTION: google.co.uk. 300 IN A 216.58.212.131 ;; Query time: 167 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Aug 20 07:32:50 CEST 2018 ;; MSG SIZE rcvd: 57

Btw : I have "Harden DNSSEC Data" checked

The Resolver is working in resolver mode, right (no forwarding) ?

edit : stupid me, answered to your initial post - didn't saw the follow up, that completely solved the "issue" already.

A good start for you might be to setup all of your DNS queries to go to unbound and configure unbound to forward to 1.1.1.1 or 9.9.9.9 (I think those support TLS) using TLS. The options for TLS aren't "check boxes" in the GUI. You have to put it in the text field of unbound advanced options.

I'm not sure what other options unbound has for meeting your requirements but it's a good place to start.

Also, block outbound port 53 and require TLS to only come from unbound (I don't remember the port. Maybe 853?) to make sure you're not accidentally allowing DNS on misconfigured machines.

@ said in DHCP Arp Table Static Entry - to bind mac to IP:

But fair enough, here's what I'd like to do.

I don't think we're trying to be condescending, but it's obvious to many of us here that you're going about this the wrong way. I pointed out a very easy way to prevent users from changing the IP address and improving security too. Many of us here have worked with computers and networks professionally. Johnpoz mentioned his background above and I first started working with LANs in 1978, currently work with them and have also done first and 3rd level support at IBM, among many other things. However, you seem to insist on ignoring advice based on experience and doing things in a way we don't think as suitable.

Anything different about those specific clients, as I certainly haven't seen this happen myself.

I have had the same error, but it only happens when the dyndns needs to update automatically. Force update works with Proxy enabled.

Same error:

/rc.dyndns.update: phpDynDNS (XXX): PAYLOAD: {"success":false,"errors":[{"code":1004,"message":"DNS Validation Error","error_chain":[{"code":9003,"message":"Invalid 'proxied' value, must be a boolean"}]}],"messages":[],"result":null}

The problem is the bogonsv6 list got too big, so you had to manually adjust the Firewall Maximum Table Entries.

This was solved a few months ago.

https://redmine.pfsense.org/issues/8417

@tguy

Yeah my thought process is from the Cisco world too and Meraki. So from Uniti inside the WLAN config you can tag your vlans you want for WLAN network segmentation, seems logical right? I had this checked for my internal wireless for VLAN 20. So on a whim I just unchecked it because the problem just felt contributing to the controller / WLAN config. After doing so boom they wireless clients started getting the correct IPs... So strange... I would have never thought that would cause an issue. To me it doesn't make sense. Although it seems with the WAPs connected to a Cisco switch in vlan 20 access mode I can still provision multiple diverse networks from the Unifi control software / WAPs. I'll use PfSense to do the traffic blocking / separation from here forward. I'm still scratching my head a bit but glad I'm working per my design.

I'd rather not, but I suppose I can just set up another instance for my DMZ. I've got some Palo Alto licenses. Maybe I'll try that instead.

@jrgx19 This looks very promising. Thank you.