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

Does it matter? It's been that way for over a decade, it's just how the ISC DHCP server works. Once all of the IPs in the pool have been used once, it becomes (essentially) random, so it doesn't matter if it starts at the beginning or end of the range.

If you need to make static assignments, keep them outside the pool/range or decrease the size of the range to account for them, and everything will be happy.