Never mind, I solved the problems saving and restoring the configuration, uninstalling the dns-server package and installing nsd from the freebsd ports instead. Configuring it was easy and it does work with classless delegation (apparently even some root servers are now using it instead of BIND). One doubt though: I tried using /etc/rc.conf.local for starting the service, but this did not work as expected. So I added the line to launch the service to the end of /etc/rc (before the exit instruction), but this seems a little hackish. Is there a more proper place to call custom scripts or commands at system startup?

Hi, this is my reported problem I think: http://forum.pfsense.org/index.php/topic,63546.0.html Bests Reiner

Apologies wallabybob - I've just realised I never got back to this thread. You were absolutely right - I got as far as testing against FreeBSD and a few mobile phones, and none of them worked. As this has to work with potentially any device I've had to abandon this idea. Damn. @wallabybob: Though this apparently works with Windows clients I think it won't work with FreeBSD clients and might not with MAC OS, Linux or Android (the client is not in the same subnet as the default gateway).

alright i can ask about the first one; but as for the second; i have triple checked my DOCSIS 3.0 signal levels are well with in tolerated bounds. ill explorer it a bit further with my ISP, but im going to have to tear my hair out if i have to deal with Taiwanese level 1 tech support for more then 5 seconds. ill keep this thread updated; but for anyone in the same situation; put a powered switch inbetween your cable modem, and the pfSense box, and you may notice your problem has been solved. thanks to wallabybob for his assistance !

Here ya go: https://github.com/pfsense/pfsense/commit/850324a23e45b3a11231f910290f8ff9b774d9bc

RFC 6762 is the one that officially defines the use of ".local" for multicast-DNS. Appendix G has a bit of discussion about other TLD names commonly used in internal networks. https://tools.ietf.org/html/rfc6762#appendix-G I had been looking for the final result of that draft you referenced, and it does seem it has expired without any further progress. It seems obvious to me to reserve a few names like this, but someone in the IETF must have a reason to not want to do so?

@Nachtfalke: I do not know exactly what these messages mean but in other threads I read that this is harmless. The developers just increases the logging output for some things which they hadn't enabled in the past. So at least the following message shouldn't make you nerveous: lighttpd[27842]: (connections.c.137) (warning) close: 11 Connection reset by peer Thanks for that news.. I am still not sure where to get info on the other error.. I have seen lots of things from searching (Google) but am not able to find any answers yet..  Will have to keep searching or hope someone else can figure this out or knows what to look for. Jon

thank you very much for the reply… i'll setup a new VM and start testing away...

I have assigned the DDNS in the WAN interface of course … After I found how to put things right in the settings I restarted my modem and then I immediately checked pfsense .... but the public ip didn't change at all ... the old one was red instead ....

Well done finding the problem. @coldmantis: pfsense LAN 192.168.1.1 - dhcp 192.168.1.50-99 pfsense WLAN 192.168.1.2 dhcp 192.168.1.100-149 It appears you don't have the interfaces bridged so they need to be on distinct IP subnets, for example LAN: 192.168.1.1/24 and WLAN: 192.168.2.1/24. PfSense does not yet support "WiFi N" though some cards which are "N capable" are supported in "G" mode. You might get better results with the WiFi by using a snapshot build of pfSense 2.1 which has much more up to date device drivers than pfSense 2.0.x.

Does the server have an IPMI sharing that interface? Some of them can share the same physical port but they're basically a different machine. Since it's up first, it could be grabbing the lease before pfSense ever comes up. I believe most cablemodems will lock to the first MAC they hand an address to and refuse the rest. I know I had similar issues running pfSense under VMWare.

4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.5 4.2.2.6

sweet that was the case! forgot completely about the outbound IP's after I changed it to the new ip it's all working! thanks!