maybe this will help? https://forum.pfsense.org/index.php?topic=81747.msg446989#msg446989

According to unbound documentation, if no root hints file is provided, it will use some "reasonable defaults".  Not sure what those are, but they're enough to get it working, but not very clean or reliable.

I always forget to just sniff the traffic.. \sigh Everything was in order - Option 3 as well as the others were what I expected them to do. The issue, as it turns out, has to do with having multiple NICs in Linux. In short, you can't always just unplug the cables and expect things to be happy. You have to ifdown and ifup the interfaces for the DHCP info to be set properly (or reboot) when you have multiple NICs. Embarrassingly, this isn't the first time I've run into this either.

I reinstalled pfsense without havp and get now the error 'This page can't be displayed' wich is i think basically the same error as that i get with HAVP installed. I have a modemrouter in front of pfsense, maybe the problem lays there. In the securitylog of that modemrouter are a lot of SYN Flood to host and TCP FIN Scan from the ip of the pfsense firewall. Is that maybe the problem?

WAN1 is a public range, I have a /28 addressable subnet. One of the IPs is statically assigned to the pfSense, one is the modem/router itself (default gateway) and a couple of the remaining ones are assigned to devices sitting "outside" the firewall - these are the ones I tested DNS lookups from whenever I get timeouts from pfSense itself. WAN2 is slightly different, I get an RFC1918 address, but have a 1:1 NAT set so I can configure port forwarding etc on the pfSense directly. No other devices between that modem/router and the pfSense WAN port. However, as I mentioned above, I disabled WAN2 altogether last time I saw the issue, and it was still happening after that, all the while DNS queries outside the pfSense were fine. I'll try your suggestion of running a packet capture on pfSense next time this happens, and will report back… Thanks. -Alex

Ah yes, that protection on switches has fooled even seasoned network veterans! For completeness' sake, the 2nd rule should be: Allow Proto IPv4 UDP SRC: 2ndLAN subnet DST: ANY (or an alias of 2ndLAN subnet and 255.255.255.255), ports 67,68 - allow DHCP Since the initial request is a discover packet sent to 255.255.255.255. Set logging on for the dhcp rule, look for hits in the firewall log You can also try tcpdump if you don't mind getting your hands dirty. Enable ssh, and connect to pfSense Note down the interface that corresponds to 2nd LAN (looks like em1) Drop to the shell and run: tcpdump -i em1 -s 0 -n -v udp port 67 or udp port 68 You should see DHCP packets from the client.

Thanks, i solved the problem. No DNS Forwarder problem o firewall rules mistake. It was an Access point TL-WA901ND V3 bug. I connected WIFI interfase and AP both to the same switch, then connect the client to the wired lan, all worked fine with the original configuration. So i discovered that the problem was an Access point bug. Googled some issues with this AP and DNS and found this "I got the DNS issue fixed only if I run the AP as DHCP Client. With a static IP (and yes still without default Gateway) any DNS request replies with the static IP address of the AP." So i changed  the fixed IP on the AP to a Dynamic IP and all worked fine on the wireless clients.

so what are your lan rules set too? while you list pfsense as your gateway - what is the dns server hand out to the clients.  If you say it resolves yahoo to its public IP.  You still have to allow it out.  Now the default lan rules should be any any and let your end 8.1 box to talk to the internet. But if you have edited these rules, or have setup a different interface its rules would be blank and you would have to create rules to allow the client out. Other possible issue is devices your trying to ping just do not answer ping and would explain timeout - if browsing is not working, this could be a proxy setup on your client that you can not get too, etc. Are you using squid on pfsense (proxy) this is another thing that is setup that could cause you problems if not correct.

who is unable to resolve your internals?  pfsense or clients - if you tell your clients to use opendns for example - how would opendns know about your internal something.somedomain.com ? You should have pfsense set to ask itself - the dns forwarder at 127.0.0.1 and google and opendns if you want it to resolve local names.

You didn't give any info that would let anyone help you..  What outside server you were using has nothing to do with anything..  Without the actual domain you were talking about your post is just gibberish that you were using opendns, or level3 or your isp, etc. Need to know what domain you are talking about, and what was their old name servers vs their new ones, etc.

I ended up putting the cable modem on a separate vswitch.

DNS simply translates a hostname to a IP address. Using a different DNS server does not mean the route to a certain IP address will be different. Answer to 1: probably an internal IP used by your ISP. Answer to 2: see above.

yes i was asking the client pfsense uses, does that send it via https or http

Am i asking to much?!  ;) You see , im going to have 4-5 pools later to be used for qos/routing/fw rules and managing all this on per device will going to be painful… Anyway, thanks for reply and spending your time on me :)

AFAIK it's been that way forever (Or at least back to the 1.2.x days).

I agree with what everyone is saying but there is a way to assign the same static IP to two different MACs. I do it if I assign a static IP to a device that has multiple interfaces (WDTV, Roku 3, TVs, Work Laptop) This is not supported by pfsense and could break your system if you mess up!!! I hold no responsible if you break your system nor do I offer support. But I am willing to share the knowledge of how it can be done You will have have to manually edit your config.xml… Goto you the <dhcpd>section then look for <staticmap>... You should get the idea of how to do this...Once you save your changes, reboot your box.. <staticmap><mac>00:19:9d:12:9f:4c</mac> <ipaddr>192.168.0.51</ipaddr> <hostname>vizio</hostname> <filename><rootpath></rootpath></filename></staticmap> <staticmap><mac>00:19:9d:08:dc:05</mac> <ipaddr>192.168.0.51</ipaddr> <hostname>vizio</hostname></staticmap> [image: Capture.JPG] [image: Capture.JPG_thumb]</staticmap></dhcpd>