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.

Hi All - Since my last post, I restarted snort BUT with the "block offenders" checkbox unchecked.  Having this checked wreaked havoc on my system.  I have been running smoothly for 32 hrs. I decided to keep SBS running DNS and DHCP. WAN = DHCP from Comcast LAN = Static 192.168.20.0 LAN DHCP = 192.168.20.2 SBS 2003 Server     IP Addresses excluded 192.168.20.1 through 192.168.20.9     IP Addresses excluded 192.168.20.100 through 192.168.20.238 DNS Server (General Setup) = 192.168.20.2 with none selected Thanks to all who replied - Brad

Pretty sure ISC dhcpd's method of assigning IPs has never changed, it's worked the way you describe it as working currently for at least 15 years, back when I started using it. Our config of it has never changed. Maybe you had reservations setup? Or something different at least, not sure what that could be. Short of assigning reservations, or changing the method you use for distributing load, don't think there's an alternative there.

None of that is indicative of someone trying to get into your network. dnsmasq re-reads /etc/hosts whenever a system inside your network gets a DHCP lease or renews one, as it has to do to maintain correct name resolution. Nothing there is unusual aside from having two dhclient PIDs though that can be normal in some unusual circumstances (like two NICs plugged into the cable modem to pull multiple IPs).

Just as a follow up, I submitted this change for review and it has been committed in github. https://github.com/bsdperimeter/pfsense/pull/69 It should appear in the next release of pfSense.

Good call Wallabybob.Thanks I just configured the trunk port. For the people who uses Cisco switch, I am pasting trunk port configurations #configure terminal #interface interface_id #switchport mode trunk #switchport trunk encapsulation {isl | dot1q} #end #show interface interface-id switchport #copy running-config startup-config

Enable NAT reflection. (check the doc wiki)

@cmb: Sure, you can add/remove fields there, just use javascript to show/hide as needed. I believe that's already done for some other providers, or at a minimum it's done in other areas of the GUI. CMB, I redid my implementation a created a new pull request: https://github.com/bsdperimeter/pfsense/pull/71 I hope that i implemented it in correct way this time, or i will give up  ::) Have a nice weekend Edson

netbios broadcast for names would use be udp port 137 yes..  So yeah if you want to resolve netbios names via broadcast then the broadcast address and that port would have to be open ;) xp and 7 still use this port.  This is the name service part of NBT, used for name registration and resolution. Yes MS awhile back added SMB over TCP which uses 445.  But I am not 100% up to speed how the name resolution works over that, I believe its more dns based using that port.  I don't believe it ever does broadcast over that port for resolution. I requested info on what package you installed sure, so I could duplicate what you have done if you were still having problems getting it to work.  But I personally don't have any need for it. I have been out of the windows support arena for a few years now, more just pure networking last few years.  So I am loosing some of my windows based info that use to be right off the top of my head. And since your working no need for me to install it ;)