Where you have a LAN interface, that's added to the hosts file to resolve the configured system hostname to the LAN IP. Unbound populates that in /var/unbound/host_entries.conf, which is how clients pointing to the DNS Resolver can resolve that hostname. That all happens by default, and there isn't a way of disabling that. I'm guessing maybe your clients are pointed to something other than the resolver for their DNS, or maybe if you changed it after attempting to do a lookup, the clients are still caching the NXDOMAIN locally.

To be clear for you, if you want to use the same host name from inside and outside your network for each camera, and each camera has a different IP address inside your network (kind of a necessary!) then you need multiple DDNS names: Host1.ddns.org Host2.ddns.org … From the outside all names names resolve to your public IP address. Then your port forwards are set up to forward a particular port to a particular internal IP address + port combination. From the inside you make a host override for each name that points directly to the inside IP address. Another partly-tricky way would be to put the cameras on a separate OPT1 interface. Then on LAN make port forwards (like you do already on WAN) that forward the various ports on LAN-IP to the various camera IP-address+port on OPT1. Then you can use just 1 DDNS name, resolving from the outside to public WAN IP, and from inside to LAN-IP. The other issue is security of web-cams on the public internet - it really would be more secure to use a VPN connection with certificates... and then conect to the cameras across the VPN.

https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf&sektion=5&apropos=0&manpath=FreeBSD+10.1-RELEASE+and+Ports#ALLOW_AND_DENY_WITHIN_POOL_DECLARATIONS When declaring permit lists for address allocation pools, the following       syntaxes are recognized following the allow or deny keywords: known-clients; If specified, this statement either allows or prevents allocation  from       this  pool  to any client that has a host declaration (i.e., is known).       A client is known if it has a host declaration in any scope,  not  just       the current scope. unknown-clients; If  specified, this statement either allows or prevents allocation from       this pool to any client that has no  host  declaration  (i.e.,  is  not       known). So this is documented behavior. e.g. one of my "host" statements in my dhcpd.conf is: host s_opt2_4 {         hardware ethernet 00:1f:3c:14:b1:6e; fixed-address 10.49.213.1; option host-name "Davis-PC_WiFi"; } If I connect to the subnet that has 10.49.213.1 inside it, then I am given that IP address. If I connect to some other LAN-style subnet/interface on my pfSense that even has "deny unknown hosts" specified like: subnet 10.49.208.0 netmask 255.255.252.0 { pool { deny unknown-clients; range 10.49.211.0 10.49.211.254; } option routers 10.49.208.250; option domain-name-servers 10.49.208.250; option custom-lan-0 07:10:C0:A8:0A:31:D4:01; } I get an IP address in the specified range of that pool, because I am a "known" host. That seems a shame! It is NOT supported to simply list hosts within a subnet{} scope - which would be an easy way to tell it that certain hosts were just restricted to that subnet. The way to do it is to use classes and sub-classes: https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf&sektion=5&apropos=0&manpath=FreeBSD+10.1-RELEASE+and+Ports#SUBCLASSES https://thelowedown.wordpress.com/2008/01/24/using-dhcp-client-classing/ http://serverfault.com/questions/472618/how-do-i-assign-hosts-to-classes-in-isc-dhcpd The way the pfSense GUI is organised, you already add static-mapped entries by interface (subnet) anyway. So the pfSense config knows which static-mapped hosts belong to which subnet. The PHP code that generates dhcpd.conf could make "class" and "subclass" statements that put all hosts for an interface into one class, then if "deny unknown clients" is selected on an interface, actually put an "allow members of "interface-xyz";" statement in the pool for that subnet. That will allow just those specified on the interface, and stop any unknown and any that are known from other interfaces. I guess nobody should be depending on the current more liberal behavior, because the GUI description already says "If this is checked, only the clients defined below will get DHCP leases from this server." - so the current behavior is technically a bug and should be tightened up to match what is claimed on the GUI. There are some situations where I would like this to work as advertised, so I will raise a redmine issue and have a look…

Yeah, so there's absolutely no problem with domain overrides. Completely misleading thread subject. You need server: root-hints: /var/unbound/root.hints (RTM) though I have no idea what's your need to mess with root hints.

Fixed, see bug linked above.

If you insist on operating an unsecure WiFi then well it's going to be unsecure. If you could develop a usage profile of the offenders and identify attributes that could be targeted without affecting your legitimate users maybe you could deter the offered enough that they lose interest.  Maybe bandwidth/throughput restriction perhaps. Another part of the usage profile might be to block sites that are unique to the offenders.  Some up front work but eventually their access becomes too limited for their purpose.

Ok thanks guys ! will investigate further :(

That makes a lot of sense!  Thanks, I appreciate you taking the time to explain it to me. As you predicted, it did indeed work with my config.  I tested out switching to unbound, leaving forwarding unchecked, choosing both WAN and WAN2 for outgoing network interfaces.  I unplugged WAN and the DNS resolution did pause a slight moment while the link was noticed as down and the gateways/routes failed over, then everything continued working solely on WAN2.

rm /var/unbound/root.key unbound-anchor -a /var/unbound/root.key chown unbound /var/unbound/root.key that fixed it

Hi, Thanks for your suggestion.  It seems an extra headache to acheive my end goal.  This wasn't an issue a few updates ago.  I used to have reverse-proxy set for OWA, but because of the issue with usiing low ports etc, I had to ditch this and publish the traffic directly to the server.  I think thats when it stop working… however, I maybe wrong.  I know there is a way round this now by setting up a loopback listioner on a higher port. I was hoping a simple fix could be put in place.  In theory, I am not sure why this wouldn't work.  I might have to go down the WPAD route if all else fails, or possible put in the fix for the reverse proxy soltuion to see if that works. Again, thanks for your comments. Ian

@johnpoz: No that is not where you put them, that hands those out to the dhcp clients of that dhcp server. As to removing ipv6 on your lan interface rules - do you want to allow IPv6, do you use IPv6?  If you remove it and you have clients trying to use ipv6 it will generate noise in your logs because it would be blocked by default rule vs allowed via your allow rule there. I won't touch the ipv6 stuff for now, since it's the default. I've put the alternative DNS sever into the settings page as suggested and I will monitor how well it works. Thanks to all who helped. PS. Looks like I can only click "Thanks" for 1 person  :-\ [image: DNS.jpg] [image: DNS.jpg_thumb]

I want to say in the WAN interface config Check the "advanced" box under "DHCP Client Configuration" and then under "Lease Requirements and Requests" You should be able to use option user-class "classID"; If the FreeBSD one doesn't support user-class, do it this way option option-77 "classID";

That's the ticket. Reverse lookup works now.

You don't have to wait for the next time.  Look at the name servers configured on the client and query them - preferably from the same client in case you're dealing with split DNS somewhere or something.  See what answers you get.

thank you, it was exactly this setting. Now the query pq team is high? [image: errodns7.jpg] [image: errodns7.jpg_thumb]

@phil.davis: What did I mess up? Forgetting all the banter about why would you do it like this, actually it should work fine. This is the same as when I put my test pfSense WAN onto my office LAN and let it get DHCP, like any other device. Behind the test pfSense is some test LAN that is hidden from the view of the office LAN. That works for me all the time. On the Airport Extreme it would be nice to know that it received a good DHCP address and DNS server… from the upstream pfSense. Then try some packet capture between Airport Extreme and pfSense to see what DNS traffic is actually going between them. I tried a packet capture on the LAN interface specifying the Airport's IP address and saw no traffic except the HTTP for the webConfigurator. So, just because, I rebooted the Airport and presto, it works. I feel stupid. But yeah,… I'm stupid. For those with the many great ideas of how I could reconfigure things to work better, I get it. In my case, there's only one cable going up to where my APs are and so I can't easily handle both my regular WiFi LAN and this "untrusted" Airport via separate NICs. I'm sure I could get something going with VLANs, but that's not a today problem. Today's problem is buying some new APs that don't suck.

Just read the sticky thread? https://forum.pfsense.org/index.php?topic=43835.0