@TgWaKu
I run DHCP off my Cisco layer 3 switch not pfsense. I recommend only 1 DHCP server per local network. Otherwise, you need to limit the scopes.

@lassesj said in openvpn client cannot resolve pfsense dns entries:

I have an idea on how to solve this.

Use your keyboard ?
Normally, you should not be able to use a host name like 'file-server' to reach this device, even it's on your own LAN.
The correct way is : fileserver.yournetwork.tld which is the full device location.

Like this :

C:\Users\Gauche>ping -4 dvr.bhf.tld Envoi d’une requête 'ping' sur dvr.bhf.tld [192.168.1.8] avec 32 octets de données : Réponse de 192.168.1.8 : octets=32 temps=9 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=2 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=3 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=4 ms TTL=64

True, Windows spoiled us a bit by adding a local network domain to the host name.

So, start being less lazy ^^, and always use the fill host name with domain name and your done ^^

@lassesj said in openvpn client cannot resolve pfsense dns entries:

Or is there anther, better way to do this?

You mean :

2284e0f5-7703-44c1-9e0d-a927ce5da562-image.png

? 😊

@Bob-Dig said in DHCPv6 server - Deny Unknown Clients ignored?:

Ops sry, I am using Kea on 24.11.

Hmm, I didn't see the edit. That may be the important point. On ISC I have tried again and what I see is weird:

If I have it set to allow only known from this interface, and enter an incorrect DUID, no leases happen (during the time I had it running, a while).

If I have it set the same but enter the correct DUID, the lease happens but a route isn't set up. Other leases to other routers DO incorrectly happen and routes may or may not be set up (comparing the leases page to the routes page).

Now the last part might well be because it was running for an hour or so and not just a half hour but it seems like the other routers should have pulled leases at some point along the way. I have no control over those routers though.

@patient0 Hi, thank you, kia should be listening on all LAN interfaces (and VIP's) it seems to run for a short time then stop, moving back ICS seems to have fixed the issue.

I don't understand why irtwould run and then stop,

@guardian said in [SOLVED] Setting up Cloudflare Dynamic DNS without using Global API Key:

Zone Resources fill in the domain name to be used (mydomain.co

Thank you! I just needed to set this up and all the other tutorials say you need a global key!

Okay, I figured it out. When I stopped Kea via the web GUI, there was still a Kea process listening on UDP 67:

sockstat -l | grep :67

So I killed the rouge Kea:

kill -9 XXXX

Then restarted Kea via the web GUI. Now the binding errors are gone, and my reservations are being honored.

Super weird issue, no idea how I ended up with two running instances of Kea.

@SkyBladeMP said in KEA DHCP Settings Tab missing:

Never thought that the CE would lag so far behind.

Netgate Releases pfSense Plus Software Version 23.09.1 and pfSense CE Software Version 2.7.2

For the new, unknown bugs, having the real sensation that your firewall is bleeding edge technology and some new gadgets, get Plus.
It's maybe better, but that's just a point of view.
The real issue is : 2.7.2 is to 'good' so there is less rush to get out a new version 😊

@DavcoreTech
Do better.
Remove these :
0fdd6781-839f-43d6-86db-e0e98803376a-image.png

or, at least, renegotiate a better contract with Google, as facebook pays more for your private DNS request as Google.
Me, IMHO, I give none of it to nobody. Why would I ?

@Luca-De-Andreis

Read this thread.
It's a bit long, but you will find the "what to do' part eventually.

Also this one.

You'll find this redmine https://redmine.pfsense.org/issues/15321, there is a patch over there. You need it.

According to https://github.com/isc-projects/kea/blob/master/doc/examples/kea4/all-options.json DHCP option "66" is known to kea, so no need to "option-def" (?) it.

{ "option-data": { "lan": [ { "name": "tftp-server-name", "data": "http://10.100.0.1" } ] } }

Btw : "lan" as you have to indicate for which interface the option should be used.

I didn't test this, the option "66".

I'm using the patch for DHCP option "114" and "43".

@darcey Thank You.

@Log1cal-Big7935 said in DNS Resolver & Outgoing interface:

if short - what should I choose in outgoing interface to have secure network

If you, as a person, can't answer that question, you still can have the safest solution right now.
It's easy, and you'll understand why.
Visit, for example, https://www.netgate.com/ and start reading. take your time.

Then, come back here, and you'll understand the next phrase , and you'll know it's true.
Ready ?
Netgate delivers the latest pfSense version with the best settings possible out of the box !
Actually quiet logic, you agree ?

There is no "When you installed pfSense, you are at risk. Do this "....." and this "....." to make it better.
If that situation existed, it would have been the default settings ....

@Log1cal-Big7935 said in DNS Resolver & Outgoing interface:

if long - I am using DNS Resolver with NextDNS (paid option) and OpenVPN.
On my hardware firewall I have 4 OPT ports and I am using each port with different VPN server (IP address).
Settings in Services>DNS resolver>General settings under Outgoing Network Interface stuck me... SHould I choose only VPN1, or should I choose all VPN interfaces that I have?

Ah, ok ... I see.
You could use (select) any of your "VPN" client interfaces, and unbound will use them, probably using a round robin method, and forwards your DNS requests to the DNS server you have set up : NextDNS.
Or select just one VPN client interface, as it really doesn't matter.

And I admit right away : it has been ages that I used a "VPN ISP", so this is what I would do to check things :
First : if unbound starts up earlier as the VPN clients, it will use whatever interfaces are selected and avaible (activated).
If later on, the VPN interfaces come up : does unbound (get) restarted to take them in account the newly activated 'WAN' interface (your VPN client interface) and use them instead of the default WAN ?

And also : does NextDNS offer "DNS over TLS" ? Because, if so, you don't care what outgoing interface unbound uses as the DNS traffic is already encrypted anyway. ( No need to tunnel into the tunnel ^^)
I think they do : Google : nextdns dns over tls and you'll get the picture.

edit : never forget the golden rule : keep things simple.

@Gertjan said in Extra IPv6 address when moving the device between vlans.:

How a ULA is generated, I don't know, but your Mac is on another network, so : another ULA.

ULA works exactly the same way as global addresses, except you set your own prefix range when you enable ULA.

@patient0 said in Dns forwarde domain override did not save:

https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/aac5bb5d396a1f1b18d59a532ad262a4d1085a40/diff

Ah understood need to export in Unified diff

@Ulrik

Aha.
See here : Feature #15321 shows how to use Option 114 in Kea and the related redmine : https://redmine.pfsense.org/issues/15321

I've added DHCP option 114 and 43 since yesterday.
It works ^^

@JKnottYes, that is the correct question, I want to install pfsense on a machine with those characteristics to manage 20k users.

@dennypage Thought I would share... I was able to track this down via packet inspection. Turns out, these errors are the result of prefix delegation requests. pfSense does not yet have support for delegation when using Kea.

FWIW, the prefix delegation requests are coming from Apple devices in the role of Matter hubs. There does not appear to be a way to turn it off.