@Felix-4 said in DDNS does not work:

However, in this case it is necessary to update at least once a month to preserve your DNS name. Therefore, in the setup I have set it to "force update" every 20 days, and due to the certificate problem it fails.

The pfSense 'dyndns' software will do a forced update after some (20 ?) days.
You saw the cache file, it contains the latest successfully updated IPv4 and something else : a time stamp value.
So pfSense knows when the last successful update happened, as it knows when to update based on the elapsed time.

If you can edit the update URL that contains the https://dyndns.dk/....., change it for http://dyndns.dk/ and your issue is gone.
True, now the traffic goes over http so its not encrypted anymore, but, imho, that's not a big deal.

@michmoor said in iCloud Private Relay:

@DefenderLLC

You're trying to get me again.......lol
let me think about this.
The biggest hurdle is converting these firewall rules. Thats a weekend task. Bad enough i have to do firewall migrations for my job but do it at home as well?

I like to use pfSense and UniFi together. In fact, that’s the way I ran it for over two years. They introduced zone based firewall rules now, so things are much more granular than they ever used to be. I guarantee you it wouldn’t take you more than a day.

@johnpoz wow, great, thanks for the quick help! works already, wonderful.

Well, not sure when i switched of to changing my DHCP server backend from ISC to Kea but that resolved it

For who may be wondering why their DHCP is not assigning leases
Step 1: Status > services > check if your dhcpd services are running or not
Step 2: In case they were not (like for me) Advanced > Networking > Set Server backend to ISC

Strange thing is despite using numerous 1-2month old backups, this sitting appears to not changed. I guess its something that isn't backed up?

Anyways, was a fun headscratcher

Hello together.
Seems almost 2 years later still an issue.
I tried out the fix with the route, only change is, that I can now ping the remote-side from the diagnostic menu.
DHCP Relay still not working.
On the remote side the is no switch, it a virtualized network without any further setting possible.
The issue might also be:
You can have only one setting for DHCP-Relay.
So if you have VLANs on the remote-side that need to communicate with the same DHCP-Server on the central side, the packets won't come from the respective VLAN-interface, and will be routed into the wrong scope of the DHCP.
What also is weird, the local DHCP in the PFSense also isn't working, or so to speak only serving the LAN-Interface, not the VLAN-interfaces althoug activated on every interface.

Wow, thanks guys! This helped me get my DHCP leases page working again. I also had reverse lookups redirected to the domain controller DNS via 'Domain Overrides' on the DNS resolver page. Somehow that did time out. I remove the overrides, and now everything works smoothly. Now I just have to figure out how to repair the overrides, or whether I need the reverse lookups for Active Directory at all. Because they obviously didn't work for a while now, and I didn't see any issues so far...

@Gorf Grab it from tcpdump or wireshark. It's truncated in the log. Should look something like this:

a3ae9da6-984e-4f95-a702-54724bd12951-image.png

@beerguzzle or just a switch capable of vlans.. Any smart switch would work.

You can then have uplink to your lan, and uplink to your opt port and they would be isolated networks on your vlan capable switch.

but sure 2 dumb switches works too.

@digitalgimpus said in Random DNS Resolver failure with Quad9 over SSL:

I'm running 1.18.0.

Yes, it is helpful in the future for posters having issues with DNS or DHCP to post the pfSense branch they are using (CE or Plus and which version). The underlying binary components of the DNS Resolver and the DHCP server are quite different between the current 2.7.2 CE branch and the latest 24.11 Plus branches, for example. A number of unbound bugs were fixed upstream in the newer version released with pfSense Plus 24.11 as compared to the much older version bundled back with pfSense 2.7.2 CE.

Ditto for kea, the new DHCP server that came out first with 2.7.2 CE. The kea binary and its connections to the DNS Resolver are quite different from (and much more feature-rich) than the original kea still bundled with pfSense CE.

When a poster does not state their pfSense version (and thus, by extension, the version of unbound or kea) they are running, it is easy for responders to make false assumptions. For instance, "it's working fine for me" might be true if you are using the latest unbound on pfSense Plus 24.11, but something may well be broken on the older unbound that is bundled with pfSense CE 2.7.2. This is a natural consequence of the growing divergence between features and versions of packages included in pfSense 2.7.2 CE and those of pfSense Plus 24.11 (and soon, 25.03).

@johnpoz Thank youuuu!!! Forgot all about this!

@sifti85 you can do whatever you want - don't make it right, running multiple layer 3 Ip ranges on the same layer 2 is just nonsense.

@rhschuld Unfortunately, I cannot recall what I did to fix this. I may have exported the backup and then edited the xml file to remove it. I did a few full re-configurations since then which might have removed it as well.

Thanx a lot @Gertjan

That was it. It was listening on port 953.

Since I had not seen any configuration option in the UI I thought it was disabled.

@tman222 localhost not really for security - but localhost would always be up, so unbound kind bind to it when starting - it will route out any wan interface you have and be natted to that ip

Not something to worry about really or set, like I said out of the box is fine - but those were things that popped into my head that are different than default.

@marcosm Oh yea, that error is definitely fixed by the patches. Thanks. I posted confirmation on that other thread in case someone else ran into it.

@nobugswanted said in Domain Override works for Debian and Windows but not Ubuntu:

Did you verify if the port forwarding worked?

How can I verify this?

You can sniff the traffic on the localhost with Diagnostic > Packet Capture.
Select the localhost interface and enter 53 at the port filter, start the capture and run a DNS lookup on the concerned machine.

So I've tested from a VPN-computer only. Maybe the solution you proposed will not work on VPN-clients.

Did you push the DNS to the VPN clients or configure the client itself to use your DNS?
Which VPN?

@Gertjan said in Devices Not Getting IP from pfSense DHCP Through TP-Link AX95 Router:

connect the "TP-Link Archer AX95 WiFi Router" to pfSense with one if it's ("TP-Link Archer AX95 WiFi Router") LAN ports, don't use the WAN port anymore.
Disable the DHCP server on the "TP-Link Archer AX95 WiFi Router".
Disable DNS.

I have followed your suggestion. It mostly seems to work. devices appear to be able to get access from the range extenders.

It does really seem to screw up the ability of the AX95 to report on its clients though. Now I can see only between 5 and 12 connected wifi devices when there are 30-35 at any one time. Also, I cannot tell any longer which of them are connected to the Guest network as opposed to the main network.

However, all my devices are now in a single broadcast domain, and OneMesh seems to still be working. these were my goals, so, thank you. :-)

Michael.
@vitorlm

Well, spent the last 15 hours trying to get my SG1100 working again. Ran into trouble at every step of the way. I need an offline installer, since the install program can't connect to the Netgate servers. (I suspect that has to do with the Starlink router using the same address space on the WAN side that pfSense defaults to use on the LAN side.)

So I don't know if I'll ever be able to get back to this. Lost 15 hours of time, plus income, plus wife's income (can't work remotely after a snow storm), and I'm wondering if my device is ever going to work again - or if I have to wait for a paycheck so I can get a new one and then just sit around and wait for it to arrive.

@Gertjan No problem! I'll have another opportunity to look into this on Friday and will report back. For now, everything seems to be working fine since the reboot.