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!

All sorted. Thank you for your time. GE

at results do you get on your client computers if you try running nslookup or dig? Here 172.16.0.1 is my pfSense system and my updstream DNS servers are OpenDNS: stan@t310:~> nslookup google.com Server:        172.16.0.1 Address:        172.16.0.1#53 Non-authoritative answer: Name:  google.com Address: 74.125.224.225 Name:  google.com Address: 74.125.224.232 Name:  google.com Address: 74.125.224.229 Name:  google.com Address: 74.125.224.228 Name:  google.com Address: 74.125.224.226 Name:  google.com Address: 74.125.224.224 Name:  google.com Address: 74.125.224.230 Name:  google.com Address: 74.125.224.227 Name:  google.com Address: 74.125.224.233 Name:  google.com Address: 74.125.224.238 Name:  google.com Address: 74.125.224.231 stan@t310:~> dig google.com ; <<>> DiG 9.9.2-P2 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 320 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.                    IN      A ;; ANSWER SECTION: google.com.            277    IN      A      74.125.224.225                                                                                                                  google.com.            277    IN      A      74.125.224.231                                                                                                                  google.com.            277    IN      A      74.125.224.238                                                                                                                  google.com.            277    IN      A      74.125.224.233                                                                                                                  google.com.            277    IN      A      74.125.224.227 google.com.            277    IN      A      74.125.224.230 google.com.            277    IN      A      74.125.224.224 google.com.            277    IN      A      74.125.224.226 google.com.            277    IN      A      74.125.224.228 google.com.            277    IN      A      74.125.224.229 google.com.            277    IN      A      74.125.224.232 ;; Query time: 1 msec ;; SERVER: 172.16.0.1#53(172.16.0.1) ;; WHEN: Mon Jun  3 09:41:19 2013 ;; MSG SIZE  rcvd: 204