@jimp: When testing with DNS tools, always end a fully qualified domain name with a "." - otherwise it will assume you want to append your system's search domain. So to lookup "www.google.com" you must use "www.google.com." The most common way that you see the behavior you are getting is if "mydomain.com" has wildcard DNS enabled, so it's responding to any query with the same reply. Due to the search domain being used, it ends up getting a response for a query that usually fails. So your problem could be solved by disabling wildcard DNS on your domain name. try without www, don't use it at all.

It can be anywhere a hostname is allowed: firewall aliases, IPsec endpoints, captive portal allowed hostnames, etc. It might be easier to download a copy of the config.xml (From Diagnostics > Command) and then search through the file to see where it is.

I have it fix by using the IP of the captive portal gateway under Services>Captive Portal>HTTPS Server Name

Hello! I think you need to bridge WAN and LAN. /illern

everey interface you assign needs a static IP address. after saving and applying this you have to go to SERVICES - DHCP server and configure the dhcp server for you interfaces LAN, OPT1, OPT2, OPT3 saving and applying this. Thats all.

Do you have a router between pfSense WAN interface and Internet? If so pfSense won't normally see changes in the public IP address. I'm using a pfSense 2.0 snapshot build and the following description applies to pfSense 2.0 which I presume you are using. When last I looked, if the WAN interface has a private IP address then the public IP address gets polled (by visiting a web site that return just the public IP address) at 1am with a change in public IP address triggering a DNS update (if dynamic DNS is configured). If you have a modem between pfSense WAN interface and the internet then the WAN interface probably has a public IP address and pfSense can see when that IP address changes and immediately trigger a dynamic DNS update. I use a dynamic DNS service. I used to have an ADSL modem/router (acting as a router) between the pfSense WAN interface and the Internet. I changed it to a modem to get prompt dynamic DNS updates.

Xtropx… NP Thanks for the info and this gives me more understanding on rules.... I see you have setup specific ports for specific services on the WAN side... Best Regards; H.

Hi… that is strange... If you have the DNS setup and the DNS server is on same inside LAN subnet is it possible the pfSense is using outside DNS gateway server? I also know Squid can cause naming issues but not sure if this is the issue either as I only ran it on one setup I was using and had name resolution through the gateway... I never checked the DNS on the internal lan as it was a small network with one static IP database. H.

Tilleback… Glad you got it going... H.

Yes.. you can do this… If you record the mac addresses of the computers you can add them to this DHCP scope... [image: 6-14-2011%205-45-37%20PM.jpg]

UPDATE… Looks like a bad hardware issue... I removed the drive and put this into another x700 and it runs! Dunno what the deal is but here is what the interface was doing... [image: 6-14-2011%204-21-27%20PM.jpg] The 3750 is running without any config and setup in default. I will have to test out the other box but it appears that something may be up with re1? Thanks for all your suggestions… UPDATE - 6/15/2011 - I tried the default OEM memory and replaced the processor to the OEM celeron - No Joy... This re1 port is still having issue. So I will use re0-re2-re3 etc. and bypass re1... Now I am not sure if anyone can trust this box...!  :-\ H.

I also find that answer from name.com confusing. First check to see if your domain translate to your public IP address http://www.servercheck.me/domain-ip-lookup/ If not verify your settings at name.com https://www.name.com/faq/how-do-I-add-a-new-dns-record

Thank you for your answer Wallybob but I just solved this. I found my solution here: http://forum.pfsense.org/index.php?topic=30653.0 I am running a vmware ESXi virtualized firewall and I was soooo sure this wasn't causing any problems :-) Well…my solution was to "enable promiscuous mode on the virtual switch port group".

Almost 3 years later and I think I've figured out the problem. It seems that you only specify the "Failover peer IP" on the first interface which will run DHCP server - not on any other interface.  In my case the first interface is the LAN, I'm not sure how pfSense decides which is the "first." In the correct setup, I have one Failover Group - "dhcp0" and it contains addresses from 192.168.1.0 and 192.168.3.0. I hope this helps someone else! Best, Martín

So simple, must have missed a step, I had to enable all traffic to pass on the wan port.

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?