Totally agree! Use AD server to act as a DHCP. Then in DNS on the server go to the DNS forwarder and put them to 8.8.8.8 google ETC and let it forward traffic on. Pfsense doesnt need to be involved really accept to make the inital connection.

Put up your OpenVN server config.

I think the problem is obvious: Config does not allow to set key "'${RNDC_KEY}'"; in /var/dhcpd/etc/dhcpd.conf subnet declaration so dhcp server ist not able to send the key. services_dhcp.php  needs an option to set this key. I think this is really a bug, because Bind9 does not accept DNS updates w/o key in a secure configuration.

Sadly it didn't: Primary DHCP system log: Nov 29 11:32:36 dhcpd: uid lease 172.19.8.56 for client f0:b4:79:ab:d9:0a is duplicate on 172.19.0.0/20 Nov 29 11:57:26 dhcpd: uid lease 172.19.8.59 for client 74:2f:68:a4:cf:b0 is duplicate on 172.19.0.0/20 Primary DHCP log: Nov 29 12:43:32 dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0 Nov 29 12:43:41 dhcpd: DHCPREQUEST for 172.19.8.127 from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:41 dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:44 dhcpd: DHCPREQUEST for 172.19.8.127 from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:44 dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:51 dhcpd: DHCPDISCOVER from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:51 dhcpd: DHCPOFFER on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:51 dhcpd: DHCPREQUEST for 172.19.8.127 (172.19.0.3) from 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:43:51 dhcpd: DHCPACK on 172.19.8.127 to 14:da:e9:33:36:5b (android-314fd0df35f688c9) via fxp0 Nov 29 12:44:39 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0 Nov 29 12:44:40 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:44:40 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:44:41 dhcpd: DHCPINFORM from 172.19.8.60 via fxp0 Nov 29 12:44:41 dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0 Nov 29 12:45:45 dhcpd: DHCPINFORM from 172.19.8.60 via fxp0 Nov 29 12:45:45 dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0 Nov 29 12:50:51 dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:50:52 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 12:50:52 dhcpd: DHCPOFFER on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:50:52 dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:50:52 dhcpd: DHCPOFFER on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:50:52 dhcpd: DHCPREQUEST for 172.19.8.50 (172.19.0.2) from 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:50:52 dhcpd: DHCPACK on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0 Nov 29 12:51:03 dhcpd: DHCPREQUEST for 172.19.8.56 from f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0 Nov 29 12:51:03 dhcpd: DHCPACK on 172.19.8.56 to f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0 Nov 29 12:52:18 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0 Nov 29 12:52:19 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:52:19 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:52:48 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0 Nov 29 12:52:48 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:52:48 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:53:05 dhcpd: DHCPREQUEST for 172.19.0.104 from d4:87:d8:cc:74:f3 via fxp0 Nov 29 12:53:05 dhcpd: DHCPACK on 172.19.0.104 to d4:87:d8:cc:74:f3 via fxp0 Nov 29 12:53:48 dhcpd: DHCPDISCOVER from 00:25:bc:95:09:72 via fxp0: load balance to peer dhcp0 Nov 29 12:53:50 dhcpd: DHCPREQUEST for 172.19.0.119 (172.19.0.3) from 00:25:bc:95:09:72 via fxp0: lease owned by peer Nov 29 12:58:08 dhcpd: DHCPREQUEST for 172.19.9.34 from 58:b0:35:11:58:7f (evert) via fxp0 Nov 29 12:58:08 dhcpd: DHCPACK on 172.19.9.34 to 58:b0:35:11:58:7f (evert) via fxp0 Nov 29 12:58:46 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0: load balance to peer dhcp0 Nov 29 12:58:47 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:58:47 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0 Nov 29 12:59:39 dhcpd: DHCPDISCOVER from 90:27:e4:77:8f:ad (Pauline) via fxp0 Nov 29 12:59:40 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 12:59:40 dhcpd: DHCPOFFER on 172.19.8.53 to 90:27:e4:77:8f:ad (Pauline) via fxp0 Nov 29 12:59:41 dhcpd: DHCPREQUEST for 172.19.8.53 (172.19.0.2) from 90:27:e4:77:8f:ad (Pauline) via fxp0 Nov 29 12:59:41 dhcpd: DHCPACK on 172.19.8.53 to 90:27:e4:77:8f:ad (Pauline) via fxp0 Nov 29 13:00:05 dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0 Nov 29 13:00:06 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 13:00:06 dhcpd: DHCPOFFER on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0 Nov 29 13:00:06 dhcpd: DHCPREQUEST for 172.19.8.51 (172.19.0.2) from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0 Nov 29 13:00:06 dhcpd: DHCPACK on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0 Secondary DHCP system log: Nov 29 12:19:49 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:01 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:14 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:29 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:36 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:37 dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:20:48 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:02 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:06 dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:11 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:20 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:29 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:34 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:42 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:43 dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:21:55 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:09 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:16 dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:16 dhcpd: bind update on 172.19.0.122 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:17 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:27 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:34 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:22:46 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:23:07 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:23:10 dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:23:14 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:23:26 dhcpd: bind update on 172.19.8.41 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:23:57 dhcpd: bind update on 172.19.0.110 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:24:16 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:24:41 dhcpd: uid lease 172.19.8.42 for client 00:23:32:1d:19:66 is duplicate on 172.19.0.0/20 Nov 29 12:25:19 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:25:33 dhcpd: bind update on 172.19.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:25:57 dhcpd: bind update on 172.19.8.48 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:28:49 dhcpd: bind update on 172.19.0.174 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:34:23 dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:34:38 dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:41:40 dhcpd: bind update on 172.19.1.75 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:41:57 dhcpd: bind update on 172.19.8.54 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:42:33 dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:43:41 dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:43:44 dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:43:51 dhcpd: bind update on 172.19.8.127 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:44:40 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:50:52 dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:51:03 dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:52:19 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:52:48 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:53:05 dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:58:08 dhcpd: bind update on 172.19.9.34 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:58:47 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Secondary dhcp log: Nov 29 12:44:40 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:44:40 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:44:40 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:44:41 dhcpd: DHCPINFORM from 172.19.8.60 via fxp0_vlan2 Nov 29 12:44:41 dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0_vlan2 Nov 29 12:45:45 dhcpd: DHCPINFORM from 172.19.8.60 via fxp0_vlan2 Nov 29 12:45:45 dhcpd: DHCPACK to 172.19.8.60 (00:21:00:b1:97:70) via fxp0_vlan2 Nov 29 12:50:51 dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0_vlan2: load balance to peer dhcp0 Nov 29 12:50:52 dhcpd: DHCPDISCOVER from 6c:e9:07:13:d1:a0 via fxp0_vlan2: load balance to peer dhcp0 Nov 29 12:50:52 dhcpd: DHCPREQUEST for 172.19.8.50 (172.19.0.2) from 6c:e9:07:13:d1:a0 via fxp0_vlan2 Nov 29 12:50:52 dhcpd: DHCPACK on 172.19.8.50 to 6c:e9:07:13:d1:a0 via fxp0_vlan2 Nov 29 12:50:52 dhcpd: bind update on 172.19.8.50 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:51:03 dhcpd: DHCPREQUEST for 172.19.8.56 from f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0_vlan2 Nov 29 12:51:03 dhcpd: DHCPACK on 172.19.8.56 to f0:b4:79:ab:d9:0a (iPod-van-Jente) via fxp0_vlan2 Nov 29 12:51:03 dhcpd: bind update on 172.19.8.56 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:52:18 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:18 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 12:52:19 dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:19 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:19 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:19 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:52:48 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:48 dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:48 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:48 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:52:48 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:53:05 dhcpd: DHCPREQUEST for 172.19.0.104 from d4:87:d8:cc:74:f3 via fxp0_vlan2 Nov 29 12:53:05 dhcpd: DHCPACK on 172.19.0.104 to d4:87:d8:cc:74:f3 via fxp0_vlan2 Nov 29 12:53:05 dhcpd: bind update on 172.19.0.104 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:53:48 dhcpd: DHCPDISCOVER from 00:25:bc:95:09:72 via fxp0_vlan2 Nov 29 12:53:49 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 12:53:49 dhcpd: DHCPOFFER on 172.19.0.119 to 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2 Nov 29 12:53:50 dhcpd: DHCPREQUEST for 172.19.0.119 (172.19.0.3) from 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2 Nov 29 12:53:50 dhcpd: DHCPACK on 172.19.0.119 to 00:25:bc:95:09:72 (Stef-Winkeleer) via fxp0_vlan2 Nov 29 12:58:08 dhcpd: DHCPREQUEST for 172.19.9.34 from 58:b0:35:11:58:7f (evert) via fxp0_vlan2 Nov 29 12:58:08 dhcpd: DHCPACK on 172.19.9.34 to 58:b0:35:11:58:7f (evert) via fxp0_vlan2 Nov 29 12:58:08 dhcpd: bind update on 172.19.9.34 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:58:46 dhcpd: DHCPDISCOVER from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:58:46 dhcpd: unexpected ICMP Echo Reply from 10.10.1.254 Nov 29 12:58:47 dhcpd: DHCPOFFER on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:58:47 dhcpd: DHCPREQUEST for 172.19.8.43 (172.19.0.3) from 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:58:47 dhcpd: DHCPACK on 172.19.8.43 to 00:16:d4:73:5c:e3 (android_7287c108d8a90392) via fxp0_vlan2 Nov 29 12:58:47 dhcpd: bind update on 172.19.8.43 from dhcp0 rejected: incoming update is less critical than outgoing update Nov 29 12:59:39 dhcpd: DHCPDISCOVER from 90:27:e4:77:8f:ad via fxp0_vlan2: load balance to peer dhcp0 Nov 29 12:59:41 dhcpd: DHCPREQUEST for 172.19.8.53 (172.19.0.2) from 90:27:e4:77:8f:ad via fxp0_vlan2: lease owned by peer Nov 29 13:00:05 dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2: load balance to peer dhcp0 Nov 29 13:00:06 dhcpd: DHCPDISCOVER from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2: load balance to peer dhcp0 Nov 29 13:00:06 dhcpd: DHCPREQUEST for 172.19.8.51 (172.19.0.2) from 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2 Nov 29 13:00:06 dhcpd: DHCPACK on 172.19.8.51 to 34:4b:50:b6:4b:19 (android_bdb252201df34e7d) via fxp0_vlan2 Nov 29 13:00:06 dhcpd: bind update on 172.19.8.51 from dhcp0 rejected: incoming update is less critical than outgoing update

What do you have pfsense set to use as dns?  127.0.0.1 or some other dns like your isp? Not sure what dns has to do with pinging??  You see the icmp on your pfsense box, are you sure it was not to some outside IP.  If you sent a ping to pfsense IP, it should respond no matter what it thinks your IP resolves too. As to what the command host returns – that is dns tool!!  Its going to query dns, not your host file.  Its like a stripped down version of dig.  its going to ask the dns server the os your running it on is configured for. If you want your pfsense box to resolve what you have setup in dns host overrides, etc.  Then you need to make sure pfsense is using the dns forwarder as its resolver and not some outside dns. now if you were to just ping your host name from pfsense, then depending if you have messed with default resolve order or not then yes host file should be used.  What does your /etc/nsswitch.conf show for your resolve order?  Should be files dns for hosts.

@AYSMAN: Sorry for being a noob.. But can anyone give a sample configuration on how I can accomplish this??? You need 1000 IP addresses for DHCP. You need 10 bits to hold 1000 addresses. Therefore out of the 32 bit IP address your network mask can be at most 32-10 = 22 bits. Your current LAN IP network is 192.168.1.0/24.  You can't just change that 192.168.1.0/22 because the right-most 10 bits will be non-zero meaning 192.168.1.0/22 is a host address. However, if you change the pfSense LAN IP network to 192.168.4.0/22 the rightmost 10 bits are zero. Then you should be able to configure DHCP range on LAN of (say) 192.168.4.10 to 192.168.7.249. If you haven't already read the linked references you should do so. The should be fairly "obvious" extensions to 2000 addresses, 4000 addresses, 8000 addresses etc, though as previously pointed out, there can be good practical reasons for not going too high.

Thanks for the added info.  Your theory of a backwards router is exactly what I was hypothesizing, but I wanted to have all of my ducks in a row and well documented before contacting them.  I don't want to loose credibility with them - they say that they only support people running Windows or MACs, you have to have a spare Windows PC to get service.  What a crock, but I won't go there.  Thank you very much.

Thanks to both of you. Worked great :)…

@johnpoz: so in dns forwarder, just create whatever host overrides you want. Worked like a charm! :) thanks! I really didn't know where i had to look for. Super, thanks!

I've always listed every domain and all sub-domains in order to have them update correctly at ZoneEdit.com. Its a bit of a pain in the ass but it works. In the "Hostname" field just list "domain1.com,sub1.domain1.com,sub2.domain1.com,domain2.com,sub1.domain2.com" etc. If anyone knows how to get the wildcard working that would be great but for now this should get you up and running.

On 2.1 I added the ability to make multiple pools each with their own settings like this and you can allow/deny access to the pools based on MAC address. So you might be able to leverage that to help with this. It's not exactly what you're after, but it's the closest way to get it done in our GUI at the moment.

@johnpoz: Yeah it does, because he using dhcp for his wan IP.  This worked, but setting his 1:1 nat to some static that was not valid.  So when he set ip to .5 for the 1:1 nat does not work. When set to dhcp and got .10 address not 1:1 nat and used his dhcp gotten wan IP to get to internet worked just fine. Thanks.

@rtabique - miles267 had issue where he was trying to use INVALID static public IPs on his wan and setting up 1:1 nat to these IPs that were not working!!  So any IP he setup a 1:1 nat for to use these bad public IPs is not going to talk on the internet.  But if it got a dhcp address and was using a different private IP that was setup in the 1:1 it used his dhcp wan IP address and worked just fine. He spread his issue about 3 different threads all about the same problem!!!  So you might think your problem is related to his when it is in fact something completely different. I find it highly unlikely your also using bad static IPs from your ISP while also trying to use dhcp on your wan interface, while also doing 1:1 nats to these bad IPs? ;) Your best bet is to start your own thread and describe the issue your having.

Hey, you're right! I rebooted and the problem went away. Thanks for the help.

Just write a small shellscript or some lines of C-code to convert it. The content is "basically" the same and it should not be that complicated to parse it. Actually i think there was already once a thread about this exact same thing and someone already wrote a parser. Have to see if the person posted it somewhere. Edit: found it: http://forum.pfsense.org/index.php/topic,25610.0.html

yes, to solve my problem i installed dhcp on a server, it has more feature than pfsense's dhcp and exactly fits my needs

thanks a lot!!!

I answer my own question, I realized that this is not a DNS problem but a NAT problem. Enabling "NAT reflection" in the NAT rules did the trick. But not for port 80, I guess I have to change the pfsense webGUI port for that one to work. Best regards, L

Yea I was worried I was going to have to do that but I guess my goal was to be energy efficient as possible and not standing up another box just for DHCP services.  My PC room already is toast haha.  Thanks for the clarification though, maybe I will think of another design which involves virtualizing pfsense and a linux distro on my atom box but then again, i don't know what the performance will look like if I do that since I plan on playing with other packages like the IPS module, etc.