If you haven't seen it: this might help you:
http://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

I fixed this up on 2.1 last week

https://github.com/bsdperimeter/pfsense/compare/752c6ca8117e05e6bb74115d2199dab7ff99168d…0a35ca7ccf198cfa6654ccc17741005a58cd6aee

How is this related to pfsense?  If you are having issues with server 2012 you really should be on a windows support board.

But if your dc is on 192.168.7 – and then you hand out clients 192.168.50 addresses, how exactly do you think they are going to talk to 7.200 for dns??

If you want  to use .50.x as your range - then change your dc to be on that network, and I would assume your using pfsense as your gateway.  Its lan IP will also have to be on this .50.x network.

How many clients? If you have a lot of clients or a large amount of lease turnover, ALIX may not have enough RAM or space for the DHCP leases file to keep up.

On 2.1 you could (though it would be a bit cumbersome) setup separate DHCP pools and put in the list of MACs on one to allow and deny on the other, and they can have unique DNS servers that way.

Of course that would only last until the kids figure out they can hardcode an IP/DNS or spoof their MAC and get around the restrictions. Separating them onto a distinct network is best, assuming they don't have physical access to the gear to switch themselves over to the other network…

How much you need to worry about that stuff really depends on how smart/sneaky/crafty the kids are :-)

@esnakk:

it seems Win XP "does something wrong" (not following standards/protocols correctly probably), When we connected a test-computer running Mac OS X everything worked fine.

Not going to say that MS does everything by the RFC's - but come on XP at one point was what 80+ % something of the market share for OSes..  You can find this sort of info at  http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10

It currently shows still having 35% of the market – that is still a shit load of computers.  If it was doing something wrong that broke networks or didn't work with devices, etc.  It would be a pretty big issue and would of never gotten any significant share of the market.

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.