It's not strictly necessary, but that's the easiest way to accommodate the routing from the host itself in multi-WAN scenarios.

Why would you try and use a video from 2012 using pfsense 2.0.1??  what version of pfsense did you install?  Current is 2.2.4 pfsense doesn't even currently use a forwarder (dnsmasq) it uses resolver unbound out of the box. What exactly are you trying to accomplish?  Are you trying to block "situs" whatever that is suppose to be - user can not even type sites correctly when posting video to youtube - and your going to follow that??  WTF??

So you have pfsense using what for its own dns?  And where do your clients point to pfsense or your some other dns?  Is this a forwarder or a resolver? Clearly those are just out of state, but pfsense can not resolve them via ptr.. which I would hope your own local IP 172.16.10.105 should have a ptr..  What is your dhcp pfsense or something else?  That 17.110 does not resolve but its owned by apple ;; QUESTION SECTION: ;218.229.119.17.in-addr.arpa.  IN      PTR ;; AUTHORITY SECTION: 17.in-addr.arpa.        7200    IN      SOA    gridmaster-ib.apple.com. hostmaster.apple.com. 2010092746 1800 900 2592000 7200

Did you wait 10 minutes before starting the slave or is the time off between the boxes? The time must match on the two boxes, although it usually logs something telling you as much.

1.  Since these are UPD packets and no rule allows passage, they are not answered by pfsense. They are not processed and passed along to their final destination.  They are dropped. 2.  I can only see them because they arrive on the interface. You can only see them because a) they arrived on the interface and, b) you have a default block rule that is set to log all blocks. 3.  There is no way to block them. You can block them from entering your network, but you cannot block them from hitting your WAN interface unless you get help from your ISP who can block them from hitting your WAN.

Well that make sense :) thanks for the your time

Wow, lots of info here, but no completely definitive answers. Here you go… You can have pfSense as your DNS/DHCP in an AD environment no problem as long as you follow a couple of rules: pfSense DHCP needs to do its own name registration in the pfSense DNS service, e.g. BIND (configured for that domain and not exposed to the outside world) pfSense DHCP needs to hand out the AD DNS server(s) in the DHCP response, not itself (very important, otherwise AD will bork in many nasty ways) AD DNS server(s) should have the pfSense as their primary forwarder(s) (not actually necessary but it simplifies things) Now, on to using the TLD internally.  Yes, it was a dumb idea, never do that, for a number of reasons, but it's there now and changing would be a giant pain and it's actually not hard to make it work. For the most part everything will actually "just work".  The only catch is that you'll need to add manual entries in either the pfSense DNS Forwarder service or in AD, (your preference, but if you use pfSense entries then make sure AD has pfSense as primary forwarder). (ETA - and don't use .local for anything either!)

well a resolver doesn't ask your isp dns for anything (unless it was authoritative for some domain your looking for)  It directly finds from roots the authoritative name servers for whatever your looking up and then goes and asks them for the records your looking for - so yeah with use of a resolver vs a forwarder your going to see queries to dns from all over the planet.. You could have clients behind pfsense that running software that queries specific dns, or devices that do.  For some strange reason some makers like to hard code specific name servers into their software/devices.  Or you could have users that manually changed their dns to something else, etc. example C:>dig pfsense.org +trace ; <<>> DiG 9.10.2-P2 <<>> pfsense.org +trace ;; global options: +cmd .                      83385  IN      NS      d.root-servers.net. .                      83385  IN      NS      i.root-servers.net. .                      83385  IN      NS      k.root-servers.net. .                      83385  IN      NS      g.root-servers.net. .                      83385  IN      NS      f.root-servers.net. .                      83385  IN      NS      m.root-servers.net. .                      83385  IN      NS      b.root-servers.net. .                      83385  IN      NS      l.root-servers.net. .                      83385  IN      NS      h.root-servers.net. .                      83385  IN      NS      a.root-servers.net. .                      83385  IN      NS      e.root-servers.net. .                      83385  IN      NS      c.root-servers.net. .                      83385  IN      NS      j.root-servers.net. ;; Received 397 bytes from 192.168.9.253#53(192.168.9.253) in 3 ms org.                    172800  IN      NS      a0.org.afilias-nst.info. org.                    172800  IN      NS      a2.org.afilias-nst.info. org.                    172800  IN      NS      b0.org.afilias-nst.org. org.                    172800  IN      NS      b2.org.afilias-nst.org. org.                    172800  IN      NS      c0.org.afilias-nst.info. org.                    172800  IN      NS      d0.org.afilias-nst.org. ;; Received 685 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms pfsense.org.            86400  IN      NS      ns3.pfmechanics.com. pfsense.org.            86400  IN      NS      ns2.pfmechanics.com. pfsense.org.            86400  IN      NS      ns1.pfmechanics.com. ;; Received 602 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 171 ms pfsense.org.            3600    IN      A      208.123.73.69 pfsense.org.            3600    IN      NS      ns3.pfmechanics.com. pfsense.org.            3600    IN      NS      ns1.pfmechanics.com. pfsense.org.            3600    IN      NS      ns2.pfmechanics.com. ;; Received 173 bytes from 162.208.119.38#53(ns2.pfmechanics.com) in 34 ms I snipped out the dnssec stuff to make that a bit cleaner looking - but see all the nameservers that were queried in the bolded lines, that is how a resolver would find pfsense.org record.  Other than that first one that had to query my name server for the . root servers.  Where the resolver in pfsense unbound has a root hints file and would not have to query for those, all the others it would query.

You could create an reverse.. But its just easier to create another record for your other interfaces IPs. So for example I have this lan - pfsense.local.lan 192.168.9.253 wlan - pfsense.wlan.local.lan 192.168.2.253 dmz - pfsense.dmz.local.lan 192.168.3.253 See attached over rides screenshot When you query ptr of 192.168.9.253 I get lan, when I query any of the others I that forward name - tells me for example which segment I am on. C:>dig -x 192.168.9.253 +short pfSense.local.lan. C:>dig -x 192.168.2.253 +short pfsense.wlan.local.lan. C:>dig -x 192.168.3.253 +short pfsense.dmz.local.lan. C:>dig -x 192.168.4.253 +short pfsense.wlanguest.local.lan. C:>dig -x 192.168.5.253 +short pfsense.ps3.local.lan. Different IPs should really have different names..  You wouldn't want all of pfsense interface IPs to return just pfsense.whatever.tld would you?  Isn't it better to give back a name that tells you what interface it is. But if you really just want a PTR for the other IPs pointing to the same name.. Just create one in the advanced section - see 2nd pic local-data-ptr: "1.2.3.4 pfsense.local.lan" [image: overridesresolver.png] [image: overridesresolver.png_thumb] [image: unboundptr.png] [image: unboundptr.png_thumb]

You could try exporting your settings via config.xml backup.  Then parse it to find out where the glitch is and localize which section of your config it's in.  Then export again but just that section.  Edit and re-import.  Completely hypothetical as I've never done it.

I am also trying to set up BIND on pfsense and no luck yet :S Could you please provide some information about what you did with your DHCP? Are you using any firewall rules? Thanks!

like to know why PTR or even forward is required for vcenter to be honest.. Seems like a useless requirement to me..  Glad you got it working though.

Thank you for the help!.. Always appreciated very much! Got it working now and all is good. Thanks again and have a nice weekend! Sincerely, Kell

@johnpoz: You can load a file into forwarder, this is how you add lots of hosts.  So if you change this file and restart forwarder you should be good. In the advanced section addn-hosts=/etc/extrahosts in that file example 192.168.1.14 test.local.lan 192.168.1.15 test2.local.lan 192.168.1.16 test.other.lan Fairly sure the detail ttl for host over rides is only like a minute so you shouldn't have to worry about local cache. Awesome, sounds perfect.