That is 1 way to do it…  You can also prevent the device from connecting to 2.4.. Its not really a "standard" and there are many different ways to skin the cat.. Have you been in a cave under a rock?  How have you not heard of band steering? ;) http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Content/ArubaFrameStyles/ARM/Band_Steering.htm https://community.arubanetworks.com/t5/Controller-Based-WLANs/What-is-the-band-steering-feature-and-how-does-it-help-us/ta-p/172154 How Band Steering Works • Controller maintains a list of 5 GHz-capable devices, which is shared with APs. • If a client connects to the 5 GHz band, it is added to the list of 5 GHz-capable devices. • If a known 5 GHz-capable device transmits probe or auth request on the 2.4 GHz band, the device is dropped initially. https://www.draytek.com/en/faq/faq-wlan/wlan.wireless-lan/what-is-band-steering/ I use band steering on my unifi, I do not have any issues with my only 2.4 connecting or seeing the ssid.  But devices that are 2.4 and 5 are almost always on the 5 unless they do not meet the min rssi I have set, etc.

How so?

NM I realise what i was doing wrong.  it should have been Host ->      xxxxxxxxxx Domain -> dyndns.com IP ->          10.0.0.22 all working!

I don't know if that kind of control/rule would even be possible within pfSense, yes you can probably do some kind of control/rule by the IP/MAC of the computer they use, but if that computer is also the same one you use then the control/rule would also affect you as well. Doing a search for YouTube parental controls shows there is a complete guide to do some control at YouTube. ref; https://support.google.com/youtubekids Please realize that whatever controls/rules you set up at home will not apply when they're at school, friends or elsewhere. Take Care and Enjoy

dhcp relay is an option.. as to this? "the pakets incomming to WAN going to the dhcp-server are also relayed to the configured dhcp-servers." Not unless you enable relay on your pfsense wan interface.. I would suggest you draw up your network.. If you were using pfsense as a downstream network router why would there be dhcp requests on the tranist network connecting pfsense to your upstream router? If your pfsense wan is 192.168.2 – how would dhcp requests for 192.168.1 network be coming into wan? So your relay your dhcp across your 192.168.2 transit to 192.168.2.2??  On its way to 192.168.1.5?

@Jimp Thank You for your guidance, it works perfect & this is what I exactly needed. @DGordon Thank you  for sharing your experience, the download link helps me a lot. I had deleted all my stale entries & restored the config file. Now my box is back to normal without any issues, Take care & Have an nice day. ;)

Doing some more digging and found this issue: On a remote PC (client), the Win7 Pro install gets a domain from an AD. So the PC has mycompany.com as domain name. I have OpenVPN installed, and as I said in my first post, everything is working fine, besides resolving names as entered in Host Overrides. When I do "nslookup -d nas.example.net", these are are the details I get: C:\Users\eduard>nslookup -d nas.example.net ------------ Got answer:     HEADER:         opcode = QUERY, id = 1, rcode = NOERROR         header flags:  response, auth. answer, want recursion, recursion avail.         questions = 1,  answers = 1,  authority records = 0,  additional = 0     QUESTIONS:         1.1.168.192.in-addr.arpa, type = PTR, class = IN     ANSWERS:     ->  1.1.168.192.in-addr.arpa         name = pfsense.example.net         ttl = 3600 (1 hour) ------------ Server:  pfsense.example.net Address:  192.168.1.1 ------------ Got answer:     HEADER:         opcode = QUERY, id = 2, rcode = NXDOMAIN         header flags:  response, want recursion, recursion avail.         questions = 1,  answers = 0,  authority records = 1,  additional = 0     QUESTIONS:         nas.example.net.mycompany.com, type = A, class = IN     AUTHORITY RECORDS:     ->  (root)         ttl = 3396 (56 mins 36 secs)         primary name server = a.root-servers.net         responsible mail addr = nstld.verisign-grs.com         serial  = 2017051701         refresh = 1800 (30 mins)         retry  = 900 (15 mins)         expire  = 604800 (7 days)         default TTL = 86400 (1 day) So what is happening, is, that windows will append example.com, to the internal FQDN that I am trying to reach, in this case nas.example.net.mycompany.com, but it should just be nas.example.net. When I do a DNS leak test, it all clears and nothing is leaked, so the remote DNS server does not see my DNS queries … Hope this makes sense. Am I missing something, or why is this not working? Cheers.

His ns1 that is the SOA being out of sync with his slaves has zero to do with the Reverse zone/PTR.. His forward has zero to do with the reverse zone.  He looks to have the /29 delegated to him in arin. He needs to point to the NS he wants to use as the authoritative for that PTR, or he needs to get with his netblocks parent to setup the PTR for him.  Really has zero to do with whatever he is doing in a forward zone.  His forward zone could be non existent for all it matters for reverse or in-addr.arpa. zones.. Now he could whatever he wanted for his local machines an that zone.. But to the public that netblock currently does not point to any server that are under his control.. Unless he has access to the swbell network AT&T..

Hi, did you ever resolved this issue? I have a similiar problem, too, Thanks Alessandro

Those are prob out of state drops.. Ie something you created a connection too, and then did not correctly close the connection or whatever and or the state expired so dd-wrt droppped it. Those ports 57839 and 57849 look to be source port for some connection you had created from a client behind dd-wrt.. Both of those Ips are owned by amazon, they resolve to a compute-1.amazonaws.com domain.  Many software packages would connect to those networks, phone home - shoot could of been you watching amazon prime video or music, etc. The only traffic that would get through to your dd-wrt wan would be something you forwarded, which clearly your not doing.  So the only thing else it would be would be answer to traffic you created.  So things would get dropped if you have issue with states expiring with connections not being closed correctly.. There is no point to running behind a double nat as any form of extra security.. And if anything can cause you problems with certain protocols, can cause issues with state tables getting out of state.. Especially if you rebooted say your dd-wrt, all the states would be gone on the dd-wrt but would still be open on pfsense and traffic what was answers to what you wanted would still be forwarded by pfsense and then dropped at dd-wrt. dd-wrt log doesn't even show you that flags on those packets - where they SYN, where they ACK?  I would assume they are just out of state..  And then yes they should be dropped.. But pfsense would do the same thing with out of state traffic.. See this doc https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection

I need some guidance please. i use expressvpn for all traffic except;   - my work laptop which has its own vpn. i route the static ip out of the wan both so get both encrypted and unencrypted depending on vpn status   - i route my voip phone out of the wan port, because over the vpn i couldn't get it working reliably my dns servers for pfsense are opendns and google. i fail dns leak tests. if i understand correctly, in this scenario i should be using dnscrypt and redirecting all client dns requests to pfsense. is that correct?

I don't think anything changes, if I disable that: [2.3.4-RELEASE][root@pfSense.kruemel.org]/root: dig @127.0.0.1 -x www.google.com ; <<>> DiG 9.11.1 <<>> @127.0.0.1 -x www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21799 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;com.google.www.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: in-addr.arpa. 3600 IN SOA b.in-addr-servers.arpa. nstld.iana.org. 2017042619 1800 900 604800 3600 ;; Query time: 219 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon May 15 17:12:46 CEST 2017 ;; MSG SIZE  rcvd: 124 and [2.3.4-RELEASE][root@pfSense.kruemel.org]/root: dig @192.168.2.200 -x www.google.com ; <<>> DiG 9.11.1 <<>> @192.168.2.200 -x www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33417 ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; Query time: 0 msec ;; SERVER: 192.168.2.200#53(192.168.2.200) ;; WHEN: Mon May 15 17:13:18 CEST 2017 ;; MSG SIZE  rcvd: 12

@S_Erickson: Hello, I'm running 2.3.2 p1 on a xg-1541 Had the same problem that you did, a blank entry at the top of the static mappings list on one of the interfaces.  Normally if you delete a static mapping it will bring you back to the top and say you have to apply the changes. With this entry after clicking OK to delete it it would simply bring me back to the top with no option to apply. I spent a couple hours trying to get rid of it before I found the solution and thought I would share it. I don't know if you still have this problem, but I couldn't find any advice online that didn't involve reinstalling or resetting to factory default configuration. So here is what I found: In my case the blank and undeletable static mapping was being created by an entry in the dhcpd.conf file. host s_opt2_0 { } Editing the file and removing these lines was not the solution though. The PfSense system pretty much ignores the dhcpd.conf file after initialization. It auto-generates a new version of the file every time the system starts based on the config.xml file. So I went in and opened up that and found a similar issue. In the static mappings section for that interface there was a line with an open/close _<staticmap></staticmap>_tag at the start of the list. Removed that, saved the file, then got rid of /tmp/config.cache to get the system to reload the config again.  Didn't even need to restart the system. Anyways I still don't know what it was that created the blank entry but at least it's gone.  Hope this helps anyone else who runs into this. Sean THANK YOU!!!!!!!!!!!

top man. It shows the expiry time in seconds too.