So in bridge mode it works fine then?  Connected to pfsense? I run a AP off my pfsense, on my normal pfsense lan and don't have any issues at all. Bridge is a bridge, should not matter what lan its connected too.  Unless you having connectivity issues to your switch behind pfsense in bridge mode it should work just fine. As to in Router mode with dhcp server on the AP – again that has nothing to do with what the AP is connected to or even if connected to anything.  If its not handing out dhcp to wireless or wired clients on its lan interface that would be the AP issue. Now if  your going to use it as router on pfsense -- pfsense would have to have routes to that network on the AP lan side.  Unless the thing is doing nat?  But again you still have to get IPs on the clients before you worry about why you can not get to the internet, etc.

For anyone else having trouble with this particular cycling nic issue, this problem has been previously documented. It was marked as resolved 2 months ago by Chris Buechler. Just as this thread indicates; http://redmine.pfsense.org/issues/1572 The only solution in my particular case was setting the "Speed and Duplex to nothing other than "default"." All cycling vanished. v2.0.1

OpenVPN clients don't register their hostnames in DNS.

Solved the problem by removing the double section "# dhpleases automatically entered" from /etc/hosts manually. I can add new static leases again, and the hosts file is not truncated anymore.

In that case, maybe they won't be a problem, so I'll look into it again. Was just hoping I could setup pfSense equivalently to OpenBSD since that's known to work and would require less configuration on other machines.

Thank you! double checked the dhcp settings and rules, made the change, everything seems to be going fine!

Check your firewall rules for that interface, make sure that the rules allow all protocols, or at least TCP and UDP both. It's not uncommon to accidentally make a rule that only passes TCP, which would behave exactly as you describe.

Ops…I never opened the backup drop down menu    :o

@yon: I have to find two solution.  I have test these solution.    :) edit /var/etc/hosts file or edit the /etc/inc/dyndns.class file. change dyndns.class file to: case 'he-net': $needsIP = FALSE; log_error("HE.net: DNS update() starting."); $server = "https://ipv4.dyn.dns.he.net/nic/update?"; curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_USERPWD, $this->_dnsHost . ':' . $this->_dnsPass); curl_setopt($ch, CURLOPT_URL, $server . 'hostname=' . $this->_dnsHost); break; or just edit hosts file add: 184.105.242.3 dyn.dns.he.net $server = "http://ipv4.dyn.dns.he.net/nic/update?";

Just an update, I did get it working. I can confirm that pfsense attempts the update when the rule is enabled, so if you're trying to set this up your bind logs should show the attempts. I considered writing it up for the wiki, but a) it doesn't seem you can just sign up and edit and b) it's mostly bind config anyway, the pfsense part is pretty self explanatory. Useful links: http://ocw.novell.com/suse-linux-enterprise-server-engineers/suse-linux-network-services/3057_01_manual.pdf  Section 1 page 36 http://www.shakabuku.org/writing/dyndns.html#listing_2

After some additional testing, it worked, with no changes on pfSense DHCP options. Maybe the DHCP client was the problem… Thanks for your help!

@jimp: The firmware check is part of it, but that only affects the dashboard. Some times when you save and it tries to restart ntpd that would really have ground things to a halt, but that should be fixed on recent builds. When it's unreachable/slow, do a packet capture on WAN looking for port 53 on your configured DNS server and see what requests are going out as you're browsing the GUI. That should help narrow down the cause. Hi Jimp, Sorry about the late reply. Yes, I will do this for you. It probably won't be until June when I have a bit more free time, but I will put this on my to-do list Thanks Jonny

I posted the code here: http://www.16paws.com/projects/pfSense/gandi.perl Andrew

I have just pasted the auth token from the website in the password field. The IP address was immediately shown in green. I guess it is working now.

There is nothing saying you have to use a forwarder.. The roots are fine, I prefer that setup myself. To me, if your going to use a forwarder (which you don't have too - I don't)  Or won't again once unbound is working on pfsense again.  Is to point to one that gets lots of traffic from other clients.. So that it has a large cache!  This is the one advantage of using a forwarder vs roots, is with lots of clients using the same dns it should have most things your looking for already looked up and cached for you. But unless you have some security concern and don't want your dns box making connections to the internet, pointing to your router that is just going to forward it again is just adding an unneeded hop - going to slow things down is all. Your router sure and the hell is not going to have a large cache of anything - so why ask it anything about dns?  Just an extra hop that adds time to the lookup and possible link in the chain that could break, etc. Now if you want some filtering features - point to opendns for example.  If you don't feel google gets enough info about you, point to googledns so they can have all your dns queries as well <joke>;) I have always liked 4.2.2.2 - its open to the public, does not do weird shit with your queries like opendns atleast use too ;)  Or just use your isp provided dns if it doesn't blow chunks as some do. But there is nothing saying you can not just have your box do the lookups directly via the root hints.  This way your sure your getting the info directly from the horses mouth so to speak, since you will go and query the owning servers directly when looking up www.somedoming.tld.  This can be a tiny fraction of ms slower, and will generate more dns traffic since you wont have a large cache to draw from.  Only clients building up your cache will be your own clients, not all the clients of your isp dns or all the users of opendns, etc.</joke>

We don't discriminate on packet sizes of any UDP or DNS. By "some firewall programs", what they're specifically referring to there is the old Cisco PIX/ASA default limit of 512 bytes on DNS requests. Almost every PIX config we see has that broken so it's undoubtedly caused numerous issues along those lines. If you're using the DNS forwarder, we default to dnsmasq's default of 4096 for –edns-packet-max, the recommended value per RFC 5625. If your Windows server does its own recursive lookups, there is no limit induced by the firewall.