Hi @viragomann! It is in router mode, and I couldn't find how to configure or enable the DHCP relay in my router.

@johnpoz Unfortunately I have far too little knowledge of the whole system and at the moment I don't have any time at all to familiarize myself with the matter.

I have reinstalled arpwatch again and observed the protocol. It runs cleanly for me. But maybe it has something to do with the fact that I recently installed pfSense 2.7.2 and the missing/incorrect certificates are therefore correct?

>>> Upgrading pfSense-pkg-arpwatch... Updating pfSense-core repository catalogue... Fetching meta.conf: Fetching packagesite.pkg: pfSense-core repository is up to date. Updating pfSense repository catalogue... Fetching meta.conf: Fetching packagesite.pkg: pfSense repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): Installed packages to be REINSTALLED: pfSense-pkg-arpwatch-0.2.1 [pfSense] Number of packages to be reinstalled: 1 [1/1] Reinstalling pfSense-pkg-arpwatch-0.2.1... [1/1] Extracting pfSense-pkg-arpwatch-0.2.1: ......... done Removing arpwatch components... Menu items... done. Services... done. Loading package instructions... Deinstall commands... done. Saving updated package information... overwrite! Loading package configuration... done. Configuring package components... Loading package instructions... Custom commands... Executing custom_php_install_command()...done. Executing custom_php_resync_config_command()...done. Menu items... done. Services... done. Writing configuration... done. >>> Cleaning up cache... done. Success

@juanzelli Glad to hear it. We're in very active development and release weekly, so if something is not right - let us know.

@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??

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.