We've had a few buglets like that over the years. Is that forwarder entry the only entry in the list? Usually with that kind of bug it has an issue removing the last item in the list, but adding/deleting additional entries works normally.

@trunix: Hmmm, the name registration propagation delay was something I hadn't considered.  Are we talking seconds, minutes or hours? If I recall correctly, one of the FAQ style pages on Dyn.com or OpenDNS.com suggested it could be of the order of minutes rather than hours. But I think that was for name changes to propagate to their own servers. It could take longer for changes to become visible in other servers.

Not a simple one really. Easiest would be to backup your config.xml, edit out the old dhcpd config for opt1, then restore it.

oh that's right, dhcrelay has to bind to the interface facing the server as well, and it doesn't support tun interfaces apparently.

Thanks, I just PM you regarding this issue. I will reply on this thread as soon as we get official response from RIPE regarding reverse DNS.

To sort by IP change the following line in /usr/local/www/services_dnsmasq_edit.php:       return strcasecmp($a['host'], $b['host']); to         return !ip_less_than($a['ip'], $b['ip']); This will sort by IP in increasing order.  Allowing a list of multiple names to be entered for the same IP is trickier because they will need to be exploded into an array, then checked individually against the existing names, which may also be a list which may need to be exploded if not stored as an array already, and checked. I don't understand the underlying data structure well enough to be sure that I'm not going to damage it by changing the 'host' element to a linear array or a space delineated list of elements.  Fortunately, space is not a valid host name component (look at the mess created by GNU make because it can't figure out if a file name has a space in it).  Nor am I confident about editing such a list.  Is there any overall guide to the data structure used by pfSense? Thanks, Andrew

I see now from interfaces_staticarp_configure($if_)_ that staticarp actually has nothing to do with dhcpd whatsoever.  It simply cribs the MAC & IP pairs from the dhcpd configuration and uses them after issuing: ifconfig $if staticarp arp -d -i $if -a which disables ARP discovery on interface $if, flushes all the existing entries, and then repopulates the ARP table with: arp -s $ip $mac Which can totally bone you if you have not prepared by entering any MAC & IP pairs.  Other than the cryptic warning, I think it would be nice to explain that this has nothing to do with DHCP, and means disabling ARP discovery for that interface.  Perhaps in the Note: or in pop-up help. But all that still doesn't explain why IP addresses must be used instead of the FQDN? Andrew

@hexcentric1: several LAN clients simply do not acquire a dhcp address from pfSense, while others do. The main problem is some routers will not acquire an address, and some PCs and Macs will not acquire an address. Does pfSense see the DHCP request from the systems which don't acquire an address? (See Status -> System Logs and click on DHCP tab)

@cmusicfan05: I checked off those two options you suggested. ("Register DHCP leases in DNS forwarder" and "Register DHCP static mappings in DNS forwarder") It is not clear to me if enabling those registrations enables registration of already existing DHCP leases and DHCP static mappings OR registration of NEW DHCP leases and NEW DHCP static mappings. That said, host overrides and DHCP static mappings in DNS forwarder work for me in pfSense 2.0.1 and 2.1. If you are trying the name lookup on Windows system please post the output of the Windows shell command ipconfig /all

I added another dns-server patch to the bug reported here: http://redmine.pfsense.org/issues/1768 This fixes a problem with local domains not being setup correctly for dnscache. Dynamic DHCP leases still do not get registered with DNS though.

http://doc.pfsense.org/index.php/DNS_Forwarder "You can also enter host and domain overrides, which will be used in place of the responses that would have otherwise come from the upstream DNS servers. This can be used for Split DNS, or making undesirable domains (e.g. myspace.com) resolve to a non-existent IP address. " This information is entered at the bottom of the Services > DNS Forwarder page.

@wagonza: Unbound backs off for certain period between 1 and 15minutes when it detects that servers are down. After 900s it should re-enable itself again. You can lower this timeout by adjusting the value for 'TTL for Host cache entries' in the advanced section. Otherwise you can also issue, from the command line, unbound-control flush_infra and service should resume. You're kidding me! Let's entertain your idea for a moment: T=00: WAN goes down T=01: Client wants to resolve a DNS. T=02: Ubound "detects that servers are down" and "backs off" T=03: Resolution fails cause WAN is down. T=22: WAN comes up T=34: Client A does ICMP echo_request to 195.186.1.110 T=35: Client A receives ICMP echo_reply from 195.186.1.110 T=50: Client B wants to resolve a DNS. T=53: Resolution fails due to ubound "taking a break" T=55: Client C wants to resolve a DNS T=57: Resolution fails due to ubound "taking a break" …. T=900: Ubound decides the nap is over and comes back into operation  ???  ??? Uh yeah. Right. You're not going to need any high availability features with services built like that, hahaha...  ;D Anyway. It doesn't seem to apply to what happened here, because one little difference: ubound didn't "re-enable" itself no more. Not after 900 secs. Not after 4 hours. Only after I manually restarted it, did it process DNS requests again. If this is a "feature" then ubound must be a M$ product!

It means that your upstream DNS server (Whatever is under System > General) is giving back private IPs for those hostnames. So you may need to disable the DNS rebinding protection under System > Advanced to get those responses.

I have 3 internal interface on the pfSense. All 3 are bridged together, the DHCP runs on this bridge. I copied over the default rules to the LAN1-3 interfaces and the Bridge interface. These rules are the Anti-lockout rule on LAN 1 and the Default allow LAN to any rule is on all interfaces. edit: Ah, it has been solved. The allow LAN to any rule was not on my Bridge interface. Sometimes it helps to have a second set of eyes. Thanks.

@wallabybob: Which DNS server are you talking about? You have enabled pfSense DNS forwarder? The build in one: dnsmasq DNS forwarder. Did you reset firewall states after adding the rules? See Diagnostics -> States and click on the Reset States tab. I've rebooted. But this way would be a lot shorter ;-) The OPTx clients are configured to use the appropriate pfSense IP address for the DNS server? Client?? Subnet. Or even better: Interface. The DNS access attempts show up in the firewall log (Diagnostics -> System Logs, click on Firewall tab) Hmmmmm. WLAN: em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet XXX.XX.XX.199 netmask 0xfffffe00 broadcast XXX.XX.XX.255 LAN: em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.181.199 netmask 0xfffffe00 broadcast 192.168.181.255 OPT1: em2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.218.2 netmask 0xffffff00 broadcast 192.168.218.255 OPT2: em3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.220.2 netmask 0xffffff00 broadcast 192.168.220.255 OPT3: em4: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.222.0 netmask 0xffffff00 broadcast 192.168.222.255 OPT4: em5: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.224.0 netmask 0xffffff00 broadcast 192.168.224.255 OPT5: em6: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.226.0 netmask 0xffffff00 broadcast 192.168.226.255 OPT6: em7: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500         inet 192.168.216.2 netmask 0xffffff00 broadcast 192.168.216.255 Now pinging the local interfaces: LAN: [2.0.1-RELEASE][root@fw.localdomain]/root(39): ping -c2 192.168.181.199 PING 192.168.181.199 (192.168.181.199): 56 data bytes 64 bytes from 192.168.181.199: icmp_seq=0 ttl=64 time=0.100 ms 64 bytes from 192.168.181.199: icmp_seq=1 ttl=64 time=0.074 ms –- 192.168.181.199 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.074/0.087/0.100/0.013 ms OPT6: [2.0.1-RELEASE][root@fw.localdomain]/root(40): ping -c2 192.168.216.2 PING 192.168.216.2 (192.168.216.2): 56 data bytes 64 bytes from 192.168.216.2: icmp_seq=0 ttl=64 time=0.096 ms 64 bytes from 192.168.216.2: icmp_seq=1 ttl=64 time=0.053 ms –- 192.168.216.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.053/0.074/0.096/0.022 ms OPT1: [2.0.1-RELEASE][root@fw.localdomain]/root(41): ping -c2 192.168.218.2 PING 192.168.218.2 (192.168.218.2): 56 data bytes 64 bytes from 192.168.218.2: icmp_seq=0 ttl=64 time=0.096 ms 64 bytes from 192.168.218.2: icmp_seq=1 ttl=64 time=0.063 ms –- 192.168.218.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.063/0.080/0.096/0.016 ms OPT2: [2.0.1-RELEASE][root@fw.localdomain]/root(42): ping -c2 192.168.220.2 PING 192.168.220.2 (192.168.220.2): 56 data bytes 64 bytes from 192.168.220.2: icmp_seq=0 ttl=64 time=0.090 ms 64 bytes from 192.168.220.2: icmp_seq=1 ttl=64 time=0.073 ms –- 192.168.220.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.073/0.081/0.090/0.009 ms OPT3: [2.0.1-RELEASE][root@fw.localdomain]/root(43): ping -c2 192.168.222.2 PING 192.168.222.2 (192.168.222.2): 56 data bytes –- 192.168.222.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss OPT4: [2.0.1-RELEASE][root@fw.localdomain]/root(44): ping -c2 192.168.224.2 PING 192.168.224.2 (192.168.224.2): 56 data bytes –- 192.168.224.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss OPT5: [2.0.1-RELEASE][root@fw.localdomain]/root(45): ping -c2 192.168.226.2 PING 192.168.226.2 (192.168.226.2): 56 data bytes –- 192.168.226.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss Only LAN, OPT6, OPT1 are working. OPT2, OPT3, OPT4, OPT5 are dead, even if defined?? Since this is complete local (pinging it's own IP) it is expected to work! Shall I suppose it to be a bug?</up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast>

Hello I'm using a Telenet Fibernet with pfSense2.0 and I am experiencing the same issue. Anyone found a solution for this one?

it was and the dhcp is now working my first problem was DHCPD was not working as the service kept dying. and not starting up. so yes thank you for your help on this and even with my isp line plugged in i still don't get internet on any of the interfaces. so now i'm trying to get the internet interface working ultimately what i want to do is this RE0  =  isp ip 123.123.123.122  =  RE1 and RE2 RE0  =  isp ip 123.123.123.123    =  Bridge1 as i have two static ip's from my ISP  and route my 122 address to my domain firewall and create a DMZ for my firewall using pfsense to do the prefiltering for  my exchange server. and use the 123 address for my game lan. segragating  both my networks but giving the speed for my online gaming. i hope this clears things up a bit more.

I'll look through that chapter and post when I've found a solution. Thanks.