@the-other yeah they like to start at one end and move through, have seen both ways - just never really paid attention to which direction pfsense likes to go.

But if his clients had IPs in the 7.x and he deleted the leases, they would still like getting their old IPs back.. The way to check if new Ips are being handed out would be to change the range so 7 is no longer available and then delete the old leases.. Then client would have to get something in the range.

Another benefit is that you can set your smtp servers so systems only can use approved mail servers. This way no device can try to start using non approved email smtp servers.

What I do with this is I made an alias
Screenshot 2023-08-21 at 8.48.44 PM.png
(SMTP US SERVERS)

Screenshot 2023-08-21 at 8.49.09 PM.png
(IMAP US SERVERS)
Screenshot 2023-08-21 at 8.52.30 PM.png
(Alias for ports)

After I create a server specific mail ACL (access control list)
Screenshot 2023-08-21 at 8.50.58 PM.png
(now my hosts can only access the approved smtp and imap servers)

The ports I have for mail can only be used for mail and for specific approved servers.

Once and a while google takes a min to resolve and send only issue.

Screenshot 2023-08-21 at 8.55.39 PM.png
(resolved automatically when they change every 5 or so mins)

Your system now will only use the approved USA servers. A couple years ago this was a big issue for some offices as the email being sent out was going to non approved servers.

You can also use "DNS over SSL" with port 853 and get some extra security.

Screenshot 2023-08-21 at 8.58.08 PM.png (DNS OVER 853)

Everything for my system uses DNS over SSL/TLS. The firewall does the SSL/TLS DNS requests for me.

You can also create access control lists on who can send DNS requests to the firewall.

Screenshot 2023-08-21 at 8.59.32 PM.png

Keep in mind devices will try to use DoH and all sorts of other ways to quarry an IP address if pfSense does it you have some more control over just opening up port 53 with a any any * * rule.

Of course you need a good NAT rule.

Screenshot 2023-08-21 at 9.03.11 PM.png

And you need a good DoH block list to really get good control
Screenshot 2023-08-21 at 9.04.24 PM.png
combineddohlist.txt

The firewall can make better use of IPS/IDS if it knows what it is resolving to.

@j-koopmann i would concur, 30 minutes for one is a low lease time.. And per dhcp specs unicast for renew is what should be used. A rebind would be broadcast.

Thanks for sharing this. The trick was to put

dhcp-lease-time 86400

in the option field instead of

option dhcp-lease-time 86400

64168062-9ae6-4e5a-a4b6-558a9e02a890-image.png

This worked and I can see the 51 request now in my DHCP request which of course is being ignored. So next round with the ISP.

Regards
JP

@johnsoga IF it's a documentation issue there's a Give Feedback link at the top of every page.

redmine.pfsense.org is where bug reports or feature requests go.

@johnsoga said in DNS Resolver Returning Unknown IP:

Having to edit the config file seems a less than ideal way to handle it

I get your point, but (again, assuming) I'd think most people would start with WAN and LAN, then add more NICs, and not just disable LAN and start using other interfaces instead. The other way would be to move one of your other interfaces/networks to igc0/lan...but not by reassigning opt1, by setting the subnet and moving the patch cable.

It would also be confusing to document and explain <lan> is not "LAN."

I just ran into the renaming because we combined two small routers with one with more interfaces, and I realized opt1 was imported as the Hurricane Electric interface, so OPT1 was opt2 internally, OPT2 was opt3, etc., and I could see that being confusing years from now. So I made HE opt10.

Still reading here. I forgot that I already have an account here.

@Zoidman If they are specific computers, and they all had dynamic DNS client software, you could allow just those dynamic DNS hostnames, via an alias in pfSense.

Otherwise yes it's possible to allow IP blocks, though that allows anyone on that ISP to connect.

AS for hardening, installing security updates for the DNS server is obviously paramount. You could also run Suricata, on WAN in your case since they would be connecting to the WAN IP.

Old post, but anyways I post my discoveries here.

To surrpress an option the easiest way is to add it to the send options under advanced. For

@JASAudiovisual Usually it's a factor of the number of leases to display/download...? FWIW I pulled up one of our data center routers which should have zero since DHCP is disabled, but has exactly one, from when I restored the config to a new router. I guess the leases file didn't get overwritten...? Anyway, it's basically instant to display the page.

@Gertjan I don't know your setup but given the bag - https://redmine.pfsense.org/issues/5413 - and many, many posts around Unbound DNS on pfsense, it is fare to say that it is not stable. Issues with restarting cache, unnecessary server restarts every time there is a client renewing IP with DHCP server and more. It has been years since the issue first was diagnosed and only recently pfsense team has resources to fix it. We all hope that this will happen soon.

For me it is not an issue since I have decided from day one that from the architecture point it makes more sense for me to run Unbound on a separate box - on enterprise LAN that is what you would want to do. If needed I complie Unbound from source myself when new fixes or version is posted. Many people dont want to do that and thats fine. I like that separation on my network.

@the-other, I took at look at the documentation and found configuration mistakes which were based on a youtuber suggestion. I made those changes and saved it. During that time logged into pfsense, I notice moving from one menu to another was very very slow. I was wondering if it was my new system or it just needed rebooting after the latest update was automatically applied. So, I rebooted the system with the corrective actions on pfsense configuration instructions. Boom, problem solved. Thanks to you and all others that lent a hand on my problem.

@remi_imer

Where are the (DHCP) logs ?
( I know, they are in your pfSense, I'm not sure if some one can come over)

Here : System > Advanced > Networking
and check

30ad5fdc-c67f-484d-976c-22a033b66d85-image.png

Now, redo your connection.

Look at the DHCP logs.
The interesting ones are from dhcp6c where c stand for client (the one who lives on the WAN) :

Example :

74df70cf-b858-4706-a949-916f2d7b5a9a-image.png

Sorry for necroing an old thread but I have the same exact issue now but this time with a totally different ISP. What the hell is wrong with this. As long as the connection is CGNAT, unbound resolving intermittently works. I'm really tired of troubleshooting this.

@johnpoz do you still have any ideas?

@Denada said in DNS:

When I try with nslookup on cmd It cannot pass traffic to 10.1.0.1

Are you saying this box can not lookup fqdn in your internal.company.com?

How would pfsense know what dns to ask for these records. If you want pfsense to lookup something off an internal dns, you would need to setup a domain override to tell unbound where to go ask.

@johnpoz We've managed to get some more IP addresses so our plan is to stop using CNAMEs on public addresses. Hopefully that will change things for the better. Thanks.

@johnpoz said in pfsense unifi dhcp problem DHCPREQUEST / DHCPACK vs DHCPDISCOVER / DHCPOFFER:

Ah -- you prob need to switch to the legacy interface to change the network name.

Ha! Yes. I flipped back to legacy, made the change and then found my way back to the new interface. Now it's the way I want it. Thanks!

networks2.png

SOLVED!

--- Lobanz

@johnpoz said in Buggy DNS behavior:

There is a big difference in the diagnostic gui dns lookup, and a client only asking unbound..

Yes I agree and that is why I already earlier wrote that it seems like expected behavior, but even so, it keeps surprising me 🙄

DNS Resolution Behavior is set to what you show:
Use Local DNS (127.0.0.1), ignore remote DNS Servers.

Forcing the use of the Resolver that is configured for DoT.

I would personally use the dns lookup in diagnostic to also check my dns setup in general (packet capture, see if there are leaks or issues).
It's just strange to see the unexpected regular dns packets and even more because the diagnostic tool is most likely generating them, but not even using them for dns (as told in my previous post).
The packets show the DNS request for what was entered.

Anyway, I will focus on clients connecting to unbound for now and make sure everything there is as expected, for whatever reason this is a choice pfSense made and is just confusing me (but I also might be easily confused).