I was using nslookup, (without the dot at the end). I thought I first noticed it using a browser but maybe not. I'll double check, Thanks!

@johnpoz: Just because the response from opendns is signed/encrypted does not mean what opendns is giving me is good info. I think we are now into the academic area. At some point you have to trust someone. Yes, OpenDNS can serve bad data sometimes as bad data can propagate through the system. A couple of questions: What exactly does DNSSEC do? Does it encrypt the traffic between the DNS and yourself? Or is it merely a way to say "OpenDNS is actually OpenDNS"? If is the latter, then I actually would prefer BOTH - a verification that the DNS actually is the real one, and encrypted traffic so no others can tamper with the data between the DNS and me. But in both these scenarios are there any way to secure that the data OpenDNS has received is actually good. That is something that will have to rely on the communication they receive. What is important to me, and the only thing I can do anything about, is to ensure that the data gets from OpenDNS to me without going through a man in the middle or in any other way gets tampered with. The DNS I use will have to take the necessary steps to ensure the data they receive is good. I can only trust that they do it, not do anything about it.

ANSWER::::::::: Hi had to create an account to lend a hand here! It's now 00:28 in the UK and after reading your 2 posts "an10bill" and hoping to find the answer when I started at about 13:00 today I thought you might want the solution: Carefull as you ARE going to KICK YOURSELF (I did!). Go to your managed switch, Look at the egress port to your modem/router that is supposed to be delivering your DHCP address, Notice the "T" (tagged packet) and change it to "U" (untagged packet), Now the packet can be understood and travel to all incompatible NICs. Our router, second in line to the satellite modem, packed in so I hadn't realised tagging was on as the old router could handle it. Only after not being able to get DHCP directly to PFSense and yet the Laptop could (like your scenario) did I eventually discover the subtle difference. Hope this helps anyone else so they dont end up on site after midnight! Ralph, Midlands PC Engineers Ltd www.mpce.co.uk

IIRC it needs to do that because in some cases the replies from the upstream server may not be directed back at the IP as expected, so by listening on that interface it can receive broadcast traffic there as well.

Joolee: If your connection isn't trustworthy and slow there are only two things you could do. Upgrade to a better dedicated connection. OR Install a local DNS server that syncs with your master DNS server over the tunnel.  It may sometimes be out of date (if the connection is down for a prolonged amount of time) but it would continue to serve requests to clients (where possible; that is if the tunnel is down the local clients cant route to remote clients, etc).

You can create a ticcket with patchfiles, than it will be implemented in next release.

Thank you, podilarius! You are right! Problem was in the Subner. Correct one is 255.255.255.252. Problem solved.

PROBLEM SOLVED!!! My state table had LOTS of this: tcp 10.10.2.30:53227 -> 10.10.1.100:631 FIN_WAIT_2:FIN_WAIT_2 CUPS was sending LOTS of requests,  I added the 10.10.2. network to CUPS on my server and now everything is back to normal!  :)

Sorry, have been out of town on business. craigduff: They are all individual (no forest). I don't think stub zones are the answer. I don't want dns on the far ends of the VPN tunnels, just on the local side with the pfsense box. I really don't want to replicate the entire zone from BIND or MSDNS to the pfsense box if I can help it. Basically what I think i'm looking for is a conditional forward. jimp: I get the whole . at the end thing (been doing that for years), however, the problem is there is no way a wildcard could be set. An example is abc.local is a domain that i would like to look up. So if i want to connect to desktop-01.abc.local the lookup should go to pfsense and pfsense see the domain then forward it to the dns server at abc.local which in return should supply the ip address of the machine. Correct me if I'm wrong or if I have missed something. I was under the impression that in pfsense the DNS Forwarder (under domain overrides) would forward dns requests for a domain to the dns controller at the ip listed.

Definitely that was the problem, change the network card and enable the DHCP server on it and now works correctly, wallabybob thank you very much your answer helped me a lot.

thanks very much for that.  When I read the notes for that option it kept referring to external sites that could be redirected (I assume this is the dominant use/need for this feature), and totally missed the local-host capability. I just did this last nite, and it works well! :)

Sounds like they need a systems administrator on site.

Dyndns services simply resolve a given hostname to your IP, they don't touch any of your traffic to your hostname. Short of getting a VPS or other server out on the Internet somewhere and connecting to it instead and having it do the port rewriting magic via netcat or similar, there isn't a solution for that.

You almost certainly don't want to have dhclient running on eth0 since that is likely to result in two different MAC addresses asking for DHCP configuration from your ISP (unless your cable modem is acting as a DHCP server). Have you checked the pfSense firewall log for signs DHCP requests has been blocked by the firewall? Have you done a packet capture in pfSense to look for DHCP traffic? @otakucode: Am I correct in thinking that if it were receiving requests, they would be recorded in the DHCP logs? Yes @otakucode: If I tell the machine to use DHCP, I end up with a garbage IP (169.x.x.x). That is the usual consequence of a machine not receiving DHCP response. @otakucode: In the VM, both the LAN and WAN connections are set to be bridged to the two physical NICs, one connected to my LAN, the other to my cable modem.  In Ubuntu, in the /etc/network/interfaces file I configured the WAN-connected interface (eth0) to receive no IP, and the other interface is set up with eth1:1 with a static IP, and eth1 with no IP. I'm not as familiar with Linux networking as I am with FreeBSD networking. What the meaning of an interface name like eth1:1? VLAN with VLAN tag 1 on physical interface eth1? @otakucode: I did notice both my adapters are now in promiscuous mode, which is apparently necessary for the bridged networking to function. Yes.

What? what is this fqdn of the phone server?  phoneserver.something.tld ? Then for something.tld you are forwarding it where?  What nameserver are you forwarding it to that can resolve hosts in something.tld? Do you have access to this server?  Can you directly query it and it resolves your phoneserver.something.tld Or do you just wan your pfsense to return IP X, say 1.2.3.4 when you ask for phoneserver.something.tld - you can have the forwarder return whatever IP you want for whatever host you want.  You do not have to forward to another server to ask for the IP of the fqdn.

Hey Guys, I really made a very, very stupid mistake :(. Seems like everything happened because I gave my client via static DHCP the same IP as the LAN interface of the pfSense machine. I just did not use my eyes nor my brain. Thanks for your support!

I'll give that a try, thanks

I have submitted this as bug to freebsd, just waiting on confirmation that it was taken, will post link to report as soon as I get it here in this thread. Ok the problem has been posted - you can follow it here http://www.freebsd.org/cgi/query-pr.cgi?pr=170279