Thank you! That was the solution. Copy instructions below. Under /var/unbound delete the following and reboot. unbound_control.key unbound_control.pem unbound_server.key unbound_server.pem

@gertjan I don't necessarily agree, although your suggestion is reasonable for some use cases. There are many, many levels of NAT throughout the interconnected networks on the internet, and adding another level of NAT in my home is not a problem in and of itself. In fact, with the right routing table, the problem that I had would not have been a problem.

@johnpoz said in Problems in address distribution in DHCP: So a standard is just nowhere at all? There are no standards in anything !! And this is really a problem but there is nothing to do. So was it like the school asked the students to donate their old home shit? The TL-WA7210N is an outdoor device - more designed for WISP.. It does have a multi-ssid mode, which from my 2 second breeze over of the manual would mean it needs to be in that mode to do that vs say the "client mode" you mentioned. All of the APs I've listed above are used for school. Some in client and some in AP So regarding these TP-Link, I'll have to think about how to move a cable there with we want VLANs The DAP‑1360 is a N repeater for gosh sake... Makes ZERO mention of vlan support. The DAP-1360 currently managed to flip all but one used as a client mode but it only gets WiFi. - He can not do some things at the same time Do not forget yet it's about D-Link Do not expect too much. Really a WBS-2400 SCT-120-FCC, So how about you go into a bit more on this wifi deployment - and how internet is actually brought into the location... So your on a WISP? for internet? You provide internet to remote building via wifi? etc. Internet access to this school comes through Fiber There are 4 such wavion of the same type, from the same model. And each institute for different places should give a reception of WiFi. These are the main APs. It's not something new they've been around for about 7 years - hoping to replace them in the coming months but right now there's no talk about it. Hope I answered everything.

Did you somehow manage to get a separate DHCP server serving both 172.20.24.0 and 172.20.25.0 since both are included in 172.20.24.0/23? Are you sure your Layer 2 is properly separating the broadcast domains?

@jobin said in DHCP Client not assigning the Auto IP: As I know, if there is no DHCP server in the network the DHCP client should assign an Auto IP in the series 169.254 according to the Zeroconf logic That depends on the OS. Windows does that, but Linux doesn't, at least not in my experience.

That would be a domain override, setup a specific domain override(s) that point to the NS you want to use for the domain your hosts are in.

@jknott said in source loopback dest loopback:953. Have I misconfigured something?: rndc — name server control utility It has something to do with BIND. As stated in original post, I'm NOT using Bind.

@gertjan Thanks for the reply. Sorry, I am not entirely sure what you are asking me to do here. I re-enabled the default check IP service.

The issue is posted here finally https://forum.netgate.com/topic/140021/dns-resolver-host-override-not-working/21

You'll need to force the client to release the address. I'm not sure on CentOS, but probably something like dhclient -r eth0 where eth0 is whatever your NIC actually is there.

That's a question for ISC-DHCPD :-) I have a vague recollection of noticing that before and trying to find out but I can't remember the result. It doesn't really matter, though. It's all dynamic so neither the client nor server should care about the order.

@jimp said in DNS flag day: Even if we pull in Unbound 1.9 the day it's released, it would go into the dev version not a release, so there will be plenty of time to test things when that happens. Exactly... But when that does happen some mention of the change might be a good thing.. Since Im with Grimson here if something fails to resolve no matter that the reason is upstream or unbound, etc. They will blame pfsense - they always blame pfsense ;) So having an official announcement about the changes that come with unbound 1.9, or Bind when it rolls into pfsense would be nice to point the users that try and blame pfsense too..

resolved, thank you... confirm that must enable DNS Forward and put to host override the nat ip internal thank you

Update: i can now ping from PC2 and can reach PC1 but i cant ping from PC1 to PC2

It's not a conflicting network, it's on the same interface! And it will just let me assign the same IP to multiple devices, and those devices will get that IP from the server and it will cause issues then as you have a conflict then. If it wouldn't be on the same network or a static IP that hasn't been acquired by DHCP would conflict that's clearly something that can't be prevented in software, but making the DHCP server give 2 devices on the same network the same address shouldn't happen without a warning that you might be doing something wrong there.

Works now! Thanks for the help.

Hello It seems to work until i reboot pfsense

Ok. So. By using my 30.10.10.in-addr.arpa and assigning my PDC's ip address (which I calles the SDC reverseLUZ Spoof), and assigning that same ip to my.domainname.tst (SDC DNS LUZ Spoof) i lost 7 of the 9 BPA flags. The last two I will solve later but since there is a list of system DNS servers usable both on WAN and LAN interface i have to figure out which one is seen as first and which one second. But most and for all little devil: yes! It can be done. It might not be advisable for obvious reasons, but yes, it can be done!