Again its not about you getting to the site or not - its the fact of resolving it... That site is also cloudflare dns..

Can you not resolve it?

$ dig www.improbable.com ; <<>> DiG 9.16.1 <<>> www.improbable.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4181 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.improbable.com. IN A ;; ANSWER SECTION: www.improbable.com. 3600 IN A 104.27.163.33 www.improbable.com. 3600 IN A 104.27.162.33 ;; Query time: 71 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Wed May 06 12:52:48 Central Daylight Time 2020 ;; MSG SIZE rcvd: 79

here is trace

$ dig www.improbable.com +trace ; <<>> DiG 9.16.1 <<>> www.improbable.com +trace ;; global options: +cmd . 81565 IN NS h.root-servers.net. . 81565 IN NS b.root-servers.net. . 81565 IN NS j.root-servers.net. . 81565 IN NS e.root-servers.net. . 81565 IN NS c.root-servers.net. . 81565 IN NS d.root-servers.net. . 81565 IN NS m.root-servers.net. . 81565 IN NS g.root-servers.net. . 81565 IN NS a.root-servers.net. . 81565 IN NS l.root-servers.net. . 81565 IN NS i.root-servers.net. . 81565 IN NS f.root-servers.net. . 81565 IN NS k.root-servers.net. . 81565 IN RRSIG NS 8 0 518400 20200519050000 20200506040000 48903 . b3rDX8hw+NlEeGXwx0uYMKtwjStmSBgr6EdkvQxqhrTHRpqyfywF0Du6 5Vy0XT9nq54eqDfK1AvD7q8rH/qc+mpd5TQoQdkpCW0wad1tZsnnwwFr VUq7H+LM3FBXc024sZG6ha7MZpdm3rDIEF1QpVjgbWpfEqEqIh9qUzlG gnKm8c9ZJLDZ8GV8bAO42miSRjaMgipCcQkZ6FZru8WFo7XiGJ+lUkpQ OIBLMm55LR5zwF4/0+Zu+fXZIay9+9S2CbPwscWqfZnJUzBCXt/Xsjdq u97c5MM2hV3wmlYRlsubnKER5RDZYJDSsKwipJekfsgo6nGo5TD2PWM8 aT82pg== ;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 3 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20200519170000 20200506160000 48903 . YyraVh9G5c5nXgKNPGsh72KnhrzpuZ5Hn55AQ7QT60SQbfxPFYN1y3D0 iySMImGx6EWg7rpxwsq/XrCyE415G2SfFzSJu27/PfgI5itPmlDeaksK DCiPDAh24ps5F8dA1gs5bEhXg6v1I4Bs9utYjVgZ//4DdlA6hUsOK41t QgWa2PDNJncShftRKwxKZbFq3b1CTvpFywIQz0WHCDfaqR1wN+wYxPrK XzpHN4Pht+9j/faQmdTBUZchCQG0/ki+Xv1ZIQ2FsfKfPK2Q+vlwYoa3 T6P3IKu6R/iM+i7i3WEkTb7mX+HC3/0YQqQotDQ51kcH0sOkzs40L+3P m03r/w== ;; Received 1178 bytes from 199.7.91.13#53(d.root-servers.net) in 12 ms improbable.com. 172800 IN NS lee.ns.cloudflare.com. improbable.com. 172800 IN NS edna.ns.cloudflare.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200513044951 20200506033951 39844 com. DQ9LaY7nv4abiSkEn0gpiP0cQ8J7yqT4l29DPEUyTure4dT/cQOGGhB4 YaB6r/2IAy0Q32WN2JIPrBQZWYFans5vdqZKOE0bT5WIOCK3TFqfmpKy wcaRIcAqloo2ucXB5WSk30r4+ep3DgkfgQyAmgDfJWM0jMEMPxRYhm3l DBVkbvRe4un6nc1i07mz7d1i25O8nmx24r929EcMKPlF4w== 3I65V3ONV364ETJ2N1O9QUJPSL5CIF78.com. 86400 IN NSEC3 1 1 0 - 3I672DQ9VK3GG4PH2A6ALH81124LCHFC NS DS RRSIG 3I65V3ONV364ETJ2N1O9QUJPSL5CIF78.com. 86400 IN RRSIG NSEC3 8 2 86400 20200513052416 20200506041416 39844 com. jBWZ6lII936oHQstMrhhjdBd4s9htotlcd/OoB7/uJqZKMNcvU8kgrc7 Pq56BylJdf3IPPCQoNQB46scFOxQDI2HHgU8dQVnNe5yVvVjL6nk4hrY qPZ+NQlk8DP7ej5fEdbLB01zYe9iiAvAHgE1K7k1ygn4kDZXQmkM2v/N P+Jb2o6TRM4NeatDghxTmh2ST1XHP/zd8Vv2OoQASH4oJQ== ;; Received 735 bytes from 192.5.6.30#53(a.gtld-servers.net) in 31 ms www.improbable.com. 300 IN A 104.27.162.33 www.improbable.com. 300 IN A 104.27.163.33 ;; Received 79 bytes from 173.245.58.109#53(edna.ns.cloudflare.com) in 25 ms

The site could be utter crap.. That is not the point.. There is one thing if he was using dns that did "filtering" and blocked it because it had xyz, or whatever.. But he is resolving, and trying to talk to the authoritative ns for that domain. Its not the ISP place to filter dns, unless they want to do that via their dns servers... He is trying to talk from his IP to some IP on the internet on port 53... Not his isp place to filter that, if that is what they are doing because they don't like whatever sites that NS my resolve..

@johnpoz I managed to add all host name by editing the host file on pihole and looking at the DHCP Leases on pfsense and match them up

Question now I have some ips showing on pihole 10.0.0.11 and 14. I have no clue what these are and they do not show in the DHCP Leases on pfsense?? where are these coming from shouldn't pf show all Leases on that page?

@interessierter said in DHCP issues:

And this device have already his static dhcp IP address, but not set directly on the device.

Devices that have a static DHCP on pfSense are included in the DNS for live, so no DNS restarts will happens when these devices asking for a new lease.

@interessierter said in DHCP issues:

that my sony beamer is asking all 5secs for a IP.

Normally, devices start their DHCP-client that asks for a lease when it's interface goes up (which implies it was down just before). Check that device.
Or, by default :

@Gertjan said in DHCP issues:

throw it out of the windows

Hi @Gertjan ,

to give you a short update - I bound DNS to all IFs and left the DHCP servers' DNS settings blank - now it works.

Many thanks for your help & KR

Functionality seems the same. I should note that other addresses internal only end in "example" as well.

Since I only want to resolve to public address for this override, is there any way I can force hostname.example to use a public DNS server like 1.1.1.1? and all other hostname2.example, hostname3.example, etc. use pfsense resolver normally.

@bhjitsense

What's your DHCP lease time from your ISP? It could be your firewall is still being assigned that address, while the computer, with a different MAC, gets a different address. Try the dhclient -r command. Then try for a new address.

Here's some info on it:

The client normally doesn't release the current lease as it is not re-
quired by the DHCP protocol. Some cable ISPs require their clients to
notify the server if they wish to release an assigned IP address. The
-r flag explicitly releases the current lease, and once the lease has
been released, the client exits.

@Orion2030 said in DHCPNAK or Offer in VLANS:

I can say that if I connect CLIENT X directly into ports on the Switch, I get IPs for VLAN2 and VLAN3 just fine ( when bi-passing ORBI) but of course I have no clue how ORBI actually handles VLANS.

As I said, that's the issue. A VLAN is nothing more than an extra 4 bytes in an Ethernet frame that a managed switch uses to separate the virtual LANs. If that ORBI doesn't handle VLANs, it can't do anything with them. In fact, since the first two of those 4 bytes are the Ethertype a router wouldn't even recognize those packets as being IP and so won't route them. A router from companies such as Cisco or pfSense can manage VLANs, but consumer level gear generally doesn't, at least not beyond guest WiFi.

I have no idea why VLAN 3 appears to be working, as it shouldn't be. I suspect you may not have what you think you do.

I found a hack to move the static mappings over: I exported the dhcp settings, edited the xml file to change the interface name, then restored the dhcp settings from the uploaded file.
There was one confusion that sometimes the dhcp settings page, which has only one tab for the one new lan interface, would not have that tab selected, so it looked like the settings were not present. Clicking on the tab showed them.
In hindsight it would probably have been better to rename the interface and assign it the new port, rather than create a new one as I did.

Noted this issue in redmine bug tracker as well: https://redmine.pfsense.org/issues/10506

The lease database size wouldn't normally reach that size... You might have a misbehaving client repeatedly making requests or otherwise causing trouble for the DHCP daemon.

You shouldn't need to manually delete or clean up leases either.

OK. Great. that works.

Thanks again.

Resolved it!

I just needed to add the Internal DNS into the 'Host Overrides' of the DNS Resolver section.

Cheers,
David

Added a package capture of outgoing DNS on WAN1 showing they are sent without FQDN
capture.pcap

I may be wrong but i thought DNS doesn't work in order so it could ask either one depending on what the client decided to ask.