@NasKar yeah thats borked..

@johnpoz Okay, a silly oversight on my part. Hard to justify a mask that's all network side. I should have caught that. However, my opinion is you're correct. A /24 would be far more common and useful as a default. Anyway, have a great new year!

@ODY-GB Yeah, both, server and client should use the same default gateway to communicate properly. The traffic seems to stop dead at this point. I'm not sure if it's because the pfSense isn't able to match up the DHCP OFFER with the original request it received as it isn't on the expected interface, or if I do need to put a firewall rule in place here. The respond from the DHCP server never reaches the client. So the client continuous sending requests as the packet capture on the guest wifi shows.

@viragomann thanks. I understand the issue now.

@johnpoz well noted, thx a lot.

@keyser Ended up opening a redmine on it: https://redmine.pfsense.org/issues/15125

@NetRunner8050 said in KEA DHCP not serving IP-Addresses: cannot lock socket lockfile https://redmine.pfsense.org/issues/14977 I also suggest staying with ISC DHCP unless you are actively testing something in Kea. There are several limitations: https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#kea-dhcp-server-feature-preview-now-available

@antgalla I do believe pfblocker can be set to return NX, but you can also just do it in unbound under custom options like posted. I am not up to speed on all the features of pfblocker, I just use it for its fancy lists that I use in my own rules.

@starbug no biggy, now you know..

@yegor I was able to get this going with little effort from the online documents - Thank you for adding this extra URL

@Methraton on your vlan 100 your blocking access to anything on the 192.168.50 network, So no that vlan100 would not be able to start a conversation to anything in that network. And you blocking access to every IP on the firewall, so no you wouldn't be able to ping pfsense IP address on the 192.168.100 or any other IP of pfsense. Unless the device on the vlan100 was using some external dns, it wouldn't be able to ask pfsense for dns either with those rules.. So Its not going to be able to go to www.google.com even unless it was using something external to resolve www.google.com Rules are evaluated top down, first rule to trigger wins, as traffic enters the interface from the network its attached too. edit: these rules look pointless.. What is the network on your LAN, sure isn't 192.168.100 or 192.168.50? That traffic would never be source into pfsense lan.. Is your lan network 192.168.100/27 ?? how would that be source of traffic into the lan interface? Going to anything on the firewall or the 192.168.50/27 network?? [image: 1703523460182-pointless.jpg] The only traffic that would be source inbound into the lan interface, is the lan subnet.. What network do you have on LAN, that is the only thing that could be source into the lan interface. Unless you were using lan as a transit/connector network - and if that was the cause you wouldn't create vlan interfaces on pfsense.. To be honest the whole thing looks a mess, all those rules on floating only make for complexity.. If you don't want vlan X to go so some where, or you want to allow it to do something - put the rule on the interface not floating..

@Grid3374 said in DNS Leak while trying to route DNS queries through VPN: "However, easier than this is to forward any DNS traffic to a public server." - which public server? You can use any public server. The points are that you forward any DNS traffic to a public server and policy route any DNS traffic (to this server) from the certain source devices to the VPN server. So all DNS traffic goes out over the VPN and hence get the VPN providers public IP.

@johnpoz pfSense is new for me. Everything else has been running a long time. I only noticed pfSense couldn't resolve local names when I installed bandwidthd. There was no need for pfSense to resolve local names before that. Thank you for the pointers to DNS overrides.

@swampland7794 I changed the DNS address to 1.1.1.1 and changed the subnet... I messed my home network and I don't have access. I'll fix it when I get home tonight and we'll see if that resolved my issue.

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

@viragomann Thanks, this seems to have done it! Couldn't figure out that the first IP in the OpenVPN servers subnet is the actually the Pfsenses Resolver.

it took a bit but now seen [image: 1703007549700-screenshot-2023-12-19-at-9.38.45-am-resized.png]

Ugh. Well I figured this out seconds after I posted. Hopefully this will help someone in the future... The syntax is the same as DigitalOcean: "Use @ to create the record at the root of the domain"

@gjkrisa said in host names 23.09.1-RELEASE (amd64): you say i should not allow static reservation? No static reservations don't reload unbound at every renewal - normal dhcp registration does those.. See the link provided by @SteveITS I reserve all the the things I would ever want to resolve, which is pretty much everything.