I can confirm that RFC 2136 DDNS updates in the latest 2.0 beta don't work either. I see nothing in the log file either.

I am able to manually update when I SSH and do a manual " nsupdate -d" to update the record.

@SeventhSon:

If your pfSense is behind NAT, this is still valid solution though.

No because it will then just register your private IP, you'll need a different dyndns client in that case.

nslookup centosservervirtual.myradon.net Server: 192.168.1.129 Address: 192.168.1.129#53 Name: centosservervirtual.myradon.net Address:   192.168.1.136 dscacheutil -q host -a name centosservervirtual.myradon.net name: pfsense.myradon.net alias: centosservervirtual.myradon.net ip_address: 192.168.1.129

It's an OSX-thing! http://discussions.apple.com/thread.jspa?threadID=2140119&start=45&tstart=0 Is a discussion about DNS and internal name resolution. I'm going to dive into that and hopefully post the sollution here.

Hi cmb

Thanks for your reply.
A friend of mine emailed me a couple of hours just the same.
In fact, logically - Actually, I should have noticed it by myself.  ::)

use its IP or setup a DNS server like BIND or tinyDNS , or use a DNS service that lets you make queries against it such as OpenDNS and create a shortcut.

ctrl-p

I was about to say that….in 1.2.3 this causes no issues on port 80. It is also solved in the jan 18 snapshot if I recall correctly.

Problem solved looks like, there was problem with cisco Catalyst 2960G switch, which was got from black market :)
Thanks all for helping!

Does the hostname given by that PC contain any non-printable characters?

It's probably trying to prevent the log from becoming corrupt with non-printable (control) characters.

I setup DHCP lease time to 7 days and my cpu reached constant 100% utilization (unless I remove the 7 days and reboot the machine) this is really weird as it is…

I solved my problem. I forgot to add first my local domain in domain category on dns forwarder ::)

Now, it work fine ^^.

@wallabybob:

You have a default route set so what you are seeing is different from the problem in the linked thread so that suggestion doesn't seem to apply.
Here's what the log on my pfSense 2.0 BETA looks like after I removed the WAN cable and restored it.

Your dhclient log reports:

Jan 17 21:16:16 dhclient: New Routers (xl0):

and your log later reports

Jan 17 21:16:20 php: : Could not find gateway for interface(wan).

In contrast, my dhclient log reports

Jan 19 09:29:49 dhclient: New Routers (vr0): 192.168.211.173

and

Jan 19 09:29:51 php: : ROUTING: change default route to 192.168.211.173

In the particular event recorded in the log extract you posted the dhcp information appears to have not included a default route. But there was a default route in the output you posted. There was an update in between?

There was no update in between the event last night and the log I posted today.  I visited the gateway tab after taking the netstat information.  I just performed a removal/restore of the WAN cable from my router and show this:

Jan 18 19:51:14 check_reload_status: syncing firewall Jan 18 19:51:17 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1 Jan 18 19:51:17 dhcpd: Copyright 2004-2010 Internet Systems Consortium. Jan 18 19:51:17 dhcpd: All rights reserved. Jan 18 19:51:17 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Jan 18 19:51:17 dnsmasq[46051]: reading /etc/resolv.conf Jan 18 19:51:17 dnsmasq[46051]: using nameserver 75.75.76.76#53 Jan 18 19:51:17 dnsmasq[46051]: using nameserver 75.75.75.75#53 Jan 18 19:51:17 dnsmasq[46051]: exiting on receipt of SIGTERM Jan 18 19:51:18 dnsmasq[22157]: started, version 2.55 cachesize 10000 Jan 18 19:51:18 dnsmasq[22157]: compile time options: no-IPv6 GNU-getopt no-DBus I18N DHCP TFTP Jan 18 19:51:18 dnsmasq[22157]: reading /etc/resolv.conf Jan 18 19:51:18 dnsmasq[22157]: using nameserver 75.75.76.76#53 Jan 18 19:51:18 dnsmasq[22157]: using nameserver 75.75.75.75#53 Jan 18 19:51:18 dnsmasq[22157]: read /etc/hosts - 2 addresses Jan 18 19:51:20 dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1 Jan 18 19:51:20 dhcpd: Copyright 2004-2010 Internet Systems Consortium. Jan 18 19:51:20 dhcpd: All rights reserved. Jan 18 19:51:20 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Jan 18 19:51:20 php: /system.php: The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 59154: No such process' Jan 18 19:51:21 check_reload_status: reloading filter ---- Jan 18 20:03:06 php: : DEVD Ethernet detached event for wan Jan 18 20:03:06 dhclient[8559]: connection closed Jan 18 20:03:06 dhclient[8559]: connection closed Jan 18 20:03:06 dhclient[8559]: exiting. Jan 18 20:03:06 dhclient[8559]: exiting. Jan 18 20:03:08 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:08 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:08 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:11 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:12 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:12 check_reload_status: Linkup starting xl0 Jan 18 20:03:12 kernel: xl0: link state changed to UP Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 php: : DEVD Ethernet attached event for wan Jan 18 20:03:13 php: : HOTPLUG: Configuring interface wan Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:13 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:14 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:14 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:14 kernel: arpresolve: can't allocate llinfo for [my_subnet].1 Jan 18 20:03:14 dhclient: PREINIT Jan 18 20:03:14 dhclient[20596]: DHCPREQUEST on xl0 to 255.255.255.255 port 67 Jan 18 20:03:14 dhclient[20596]: DHCPACK from 73.117.224.1 Jan 18 20:03:14 dhclient: REBOOT Jan 18 20:03:14 dhclient: Starting add_new_address() Jan 18 20:03:14 dhclient: ifconfig xl0 inet [my_subnet].155 netmask 255.255.254.0 broadcast 255.255.255.255 Jan 18 20:03:14 dhclient: New IP Address (xl0): [my_subnet].155 Jan 18 20:03:14 dhclient: New Subnet Mask (xl0): 255.255.254.0 Jan 18 20:03:14 dhclient: New Broadcast Address (xl0): 255.255.255.255 Jan 18 20:03:14 dhclient: New Routers (xl0): [my_subnet].1 Jan 18 20:03:14 dhclient: Adding new routes to interface: xl0 Jan 18 20:03:14 dhclient: /sbin/route add default [my_subnet].1 Jan 18 20:03:14 dhclient: Creating resolv.conf Jan 18 20:03:14 apinger: ALARM: WAN([my_subnet].1) *** down *** Jan 18 20:03:14 apinger: alarm canceled: WAN([my_subnet].1) *** down *** Jan 18 20:03:14 check_reload_status: rc.newwanip starting xl0 Jan 18 20:03:14 dhclient[20596]: bound to [my_subnet].155 -- renewal in 172800 seconds. Jan 18 20:03:15 php: : rc.newwanip: Informational is starting xl0. Jan 18 20:03:15 php: : rc.newwanip: on (IP address: [my_subnet].155) (interface: wan) (real interface: xl0). Jan 18 20:03:15 php: : ROUTING: change default route to [my_subnet].1 Jan 18 20:03:15 check_reload_status: reloading filter Jan 18 20:03:15 check_reload_status: reloading filter Jan 18 20:03:15 apinger: Exiting on signal 15. Jan 18 20:03:16 check_reload_status: reloading filter Jan 18 20:03:17 apinger: Starting Alarm Pinger, apinger(32075) Jan 18 20:03:31 dnsmasq[22157]: reading /etc/resolv.conf Jan 18 20:03:31 dnsmasq[22157]: using nameserver 75.75.76.76#53 Jan 18 20:03:31 dnsmasq[22157]: using nameserver 75.75.75.75#53

Notably, it reports that it has the correct default route:

Jan 18 20:03:15 php: : rc.newwanip: on (IP address: [my_subnet].155) (interface: wan) (real interface: xl0).

Is it possible that the NTPD error above just before I unplugged has something to do with it?  I'd assume no, but I'm not sure if the general error has a bigger tell.