Thanks or the clarification, jimp. I'll try to use it in this correct manner in future, thanks. As for: host -v thisdoesnotexist.mydomain.com. , it actually does exists & the name resolution returns 216.34.94.184 (pop the address in a browser & it returns the MyDomain registrar's landing-page) That's why I've been using foo.bar as a bogus DNS value. As best I can tell, when I do a host -v lookup on my own (primary) domain, everything looks in order. I'm also running a reverse-proxy on my network, so that I can redirect HTTP(s) requests for multiple domains & sub-domains fairly easily to different hosts. I'm not sure that that could cause such issues, but I'm just throwing it in there for reference-sake.

Hmmm, ok. That is a good suggestion. There are differences in routing table. On node 1 there are entries for the peers, on node 2 are these peer routes missing. But that should not make any influence, since some peer ip addresses are pingable, others not - even with these different routing tables. Node 1: Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            192.168.2.254      UGS        0 118708283  bge0 10.5.0.0/22        link#13            U          0 69244840 em0_vl 10.5.0.1          link#20            UH          0    1188  vip3 10.5.0.2          link#13            UHS        0        6    lo0 10.10.37.0/24      link#3            U          0    25859    em2 10.10.37.1        link#26            UH          0        0  vip9 10.10.37.2        link#3            UHS        0        0    lo0 127.0.0.1          link#8            UH          0      266    lo0 192.168.0.0/24    link#12            U          0  3064447 em0_vl 192.168.0.1        link#19            UH          0        0  vip2 192.168.0.101      link#12            UHS        0        0    lo0 192.168.4.0/24    link#2            U          0  1920393    em1 192.168.4.1        link#24            UH          0        0  vip7 192.168.4.2        link#2            UHS        0        2    lo0 192.168.6.0/24    link#14            U          0        0 em0_vl 192.168.6.1        link#21            UH          0        0  vip4 192.168.6.2        link#14            UHS        0        0    lo0 192.168.7.0/24    link#15            U          0        0 em0_vl 192.168.7.1        link#22            UH          0        0  vip5 192.168.7.2        link#15            UHS        0        0    lo0 192.168.60.0/24    link#16            U          0 23881393 em1_vl 192.168.60.1      link#25            UH          0        0  vip8 192.168.60.2      link#16            UHS        0        0    lo0 192.168.66.0/24    link#6            U          0 73122252  bge1 192.168.66.1      link#23            UH          0        0  vip6 192.168.66.2      link#6            UHS        0        2    lo0 192.168.2.0/24    link#5            U          0  9838447  bge0 192.168.2.10      link#17            UH          0        0  vip10 192.168.2.20      link#5            UHS        0        0    lo0 192.168.2.22      link#18            UH          0      243  vip1 192.168.2.31      link#27            UH          0        0  vip11 Node 2: Internet: Destination        Gateway            Flags    Refs      Use  Netif Expire default            192.168.2.254      UGS        0  182600    em0 10.5.0.0/22        link#11            U          0  104151 em1_vl 10.5.0.3          link#11            UHS        0        0    lo0 10.10.37.0/24      link#17            U          0        0 em1_vl 10.10.37.3        link#17            UHS        0        0    lo0 127.0.0.1          link#6            UH          0      526    lo0 192.168.0.0/24    link#10            U          0    1528 em1_vl 192.168.0.102      link#10            UHS        0        2    lo0 192.168.4.0/24    link#15            U          0    1026 em1_vl 192.168.4.3        link#15            UHS        0        0    lo0 192.168.6.0/24    link#12            U          0        0 em1_vl 192.168.6.3        link#12            UHS        0        0    lo0 192.168.7.0/24    link#13            U          0        0 em1_vl 192.168.7.3        link#13            UHS        0        0    lo0 192.168.60.0/24    link#16            U          0  335071 em1_vl 192.168.60.3      link#16            UHS        0        0    lo0 192.168.66.0/24    link#14            U          0    59040 em1_vl 192.168.66.3      link#14            UHS        0        0    lo0 192.168.2.0/24    link#1            U          0  250104    em0 192.168.2.21      link#1            UHS        0        0    lo0

Thanks, I had the same problem and unchecking DNS Rebind Check fixed it. It only surfaced though after we implemented a squid proxy and forced all traffic through it (using a wpad.dat file). I suppose that before the DNS-requests never reached the PFsense box, but were sent directly to the domain controller?

I may take a look at that. What I'm really trying to achieve is redundant DHCP + DNS + DDNS, but looking at TinyDNS it seems as though the DDNS part is an add on.  I haven't looked into it enough to figure out how the DDNS component works. I suspect that I will just use two other servers on the network to set this up, but it would be really nice if this were possible with pfSense.

Just in case noobs like me find this: I setup syslog for remote on a linux box (by adding a '-r' flag in its config), then in pfSense 1.2.3 I went to Status->System Logs->Settings, entered in the linux box's IP, and checked 'Everything'. If you check 'Everything' and another box, you'll receive two of the same message.

Thanks Brother i have done it and it is working very fine…. Regards Ahsan Abid

yes i understand thank you

Thank you for the advice. I'll look at hardwiring something in /etc/inc/. I realize that mixing subnets is not the ideal situation, but I hesitate to buy extra hardware to accommodate the 10 or so visitors per year who come to the office and ask if they can hook up their laptop. I also think it's rude to say "NO you can't hook up your laptop," since they let me hook up my laptop when I visit their office. Assigning visitors an IP address on a different subnet with stricter rules is a cheap and easy way to avoid problems like visitors being able to browse our samba shares. It also would prevent problems like we had when a temp that we hired to help us with filing happened to have a torrent client running in the background on his laptop, and we got a DMCA notice because of an illegal download. Since only 5 or 6 ports are open from that subnet to WAN, the torrent client wouldn't have worked. I know it won't stop the NSA or a malicious hacker, but that's not the kind of people we invite into our office anyway.

@wallabybob: After a bit of experimentation I discovered pfSense will let you assign the same IP address to two different MAC addresses but the hostnames have to be different. In pfSense I assigned the IP address associated with my netbook's wired interface to the wireless MAC address on my netbook and disabled and enabled the wireless interface and it successfully got the IP address I had previously associated only with the wired interface's MAC address. I can put up with two different names for the same IP address. Now my automatic backup will run regardless of whether the netbook is online through the wired interface or wireless interface. Nice.  I'll have to try it when I get home.

Really NO-ONE really ever needed this?

Configure your domain overrides through the webGUI. Go to Services->DNS Forwarder. Unbound makes use of the same host entries and domain overrides as dnsmasq.

Just wanted to say that it did come down to a hardware issue of some sorts. Not sure what is up with the PCI port for NIC I was using for the WAN interface but switch the interface assignment and I am able to view sites and download w/o issue. Thanks for the advice on the HW!

Sorry about being unclear. Clarifications: LAN is vlan0, OPT1 is vlan1 I added pass all rules, meaning pass on any proto, any destination, on both LAN and OPT1 interfaces. The tcpdump was looking for DHCP protocol packets, I used this command: tcpdump -i <if>port 67 or port 68 The log excerpt was from the firewall log, forgot to say there was a green pass icon too. Sorry. The DHCP-specific rules that I added (on both LAN and OPT1) was "PASS UDP from anywhere, to anywhere, port 67-68". Again, excuse me for being vague, and thanks for your time.</if>

DNS from DHCP should be fixed with any snapshot from late Saturday on.

This is strange. If I enable and disable the WAN adapter in pfSense I get one IP, and if I dhclient I get another. I can do this back and forth. In fact, since the last few days of pfSense updates, my /var/etc/resolv.conf file hasn't been populating anything but the domain so I've lost connection via hostnames because of it. What in the world is causing this?