@jimp:

If you specify an allow MAC, all others are denied.

If you specify a deny MAC, all others are allowed.

Excellent, thanks.  That's exactly what I was hoping was the case.

Either turn on NAT reflection, or use split DNS - on pfSense DNS forwarder define host overrides that give the internal LAN IP of the various server/s in response to internal requests for the name.

Looking at dhcpd.log, I see some human readable lines, then a lot of "@^@^@^@^@", then it ends with "^@CLOG^@^@^@^@[<f3>^@^@|<d0>^G^@^@^@^@^@"[/quote]
The logs are circular logs - maybe you are using "cat" to spit out the log at the command line, and you need to use the "clog" utility?

clog dhcpd.log ```</d0></f3>

sweet, thanks guys for all the help and pointing me in the right direction.  ;D

Ah! That'll do.

Yes, when the pfSense WAN IP is a private one, the Dynamic DNS code is smart enough to use checkip.dyndns.org to find out what its real public-facing IP is, and use that to set the Dynamic DNS name.
Of course, on your ISP device you will need to port forward ports in from ISP WAN to pfSense WAN, so that your clients in big bad internet land actually get through to pfSense WAN. Often with ISP devices they have a place to specify a "DMZ" IP address which is not a DMZ at all, it does a 1:1 port forward of everything to the specified IP address - which is what I always do. Then I get all the crap connection attempts from the public internet passed through to pfSense where I can filter (and log them if I care).

Jan 23 00:58:00 php: rc.dyndns.update: MONITOR: LTEPGW is down, removing from routing group Privat

Those messages are spat out by /etc/inc/gwlb.inc return_gateway_groups_array() - whenever it is called it looks through all the gateway groups, calculates and returns the lists of gateways in each group that are up. As it does the calculations it logs any gateways that are down, regardless of whether the caller actually cares about the particular gateway or GWG. It could be cleaned up to not spam the logs like that!
For you, it is just log noise. The dynamic DNS code will still be doing its thing OK.

johnpoz,

Thank you for the reply. What you explained makes perfect sense in regards to the workstations being assigned their previous ip address in the dhcp pool. I am not going to delete all the leases in the dhcp gui for now,,Had plenty of work getting ip range changed over on the DC and such.

The idea of the dhcp server assigning from high to lowest numbers doesn't seem to be holding true. The mobile devices seem to be getting 192.168.2.x number and i see only one 192.168.3.x device so at least I know the range is going into the "3" range.
I guess the only way we will ever know if the "0" range is used if the device count goes beyond ,,about 750 devices on the lan at one time.

Barry

^ my bad, yes domain overrides.. Just bottom of page under host over rides section under dns forwarder ;)

Seems that I've found the solution to this problem.. Or unless it is working for me for some time without a problem.

Go to "Services: DNS forwarder".

Uncheck: "Register DHCP leases in DNS forwarder"

Save & Apply

Uncheck: "Register DHCP static mappings in DNS forwarder"

Save & Apply

Re-enable the above and Save & Apply in reverse order

I'll still checking, but unless now I've my host list complete and without a reboot.

ok i get it working, i just shrink the dhcp range in a half and the other half is for ip assignment.

Correct - make a DHCP range that is a part of the LAN subnet. Then allocate static-mapped entries to addresses outside the DHCP range.
If you do not want to give out DHCP to unknown clients (ones that have no MAC-address entry) then there is a checkbox to deny unknown clients. When doing that, you could make the DHCP range really small, because nothing is allowed to use it anyway.

Thanks a lot…

@albrandwood:

So I tested it, and was able to confirm (at least with 2.0.1) you can use the "server=/domain/ip" command in the advanced option box, if it is followed by "rebind-domain-ok=/domain/"

eg:

server=/domain/192.168.0.1
server=/domain/192.168.0.2
rebind-domain-ok=/domain/

@

Did this actually work? Specifically, does this actually properly allow /domain/ to resolve DNS entries via either of 192.168.0.1 or 192.168.0.2 - so that your domain overrides are not 'single point of failure'?

The code that parses the text in the Advanced box allows the parameters to be separated by spaces. It puts "–" in front of every space-separated chunk of text. That does not work in your case! The code has to either be smarter and parse the input more (like ignoring space inside of quoted strings) or disallow space-separated parameters - make people put a new-line between every parameter.

It is a CPE, that can connect to internet over xDSL or over LAN interface.

On bootup, the CPE makes a discover on lan interface and if option 43.1 is offered, the CPE switches from xDSL to internet over LAN. But by design, the CPE is only listening passive if the DHCP server offers this option. It is not in the Parameter Request List.

Thx

What firewall rule/s have you got on the various other VLAN interfaces in pfSense?
You will need to allow traffic for protocol TCP+UDP source VLAN2net destination VLAN2address port 53 (DNS) …
If you have blocked off all access to VLAN2address, then that will block off the DNS also.

When things like that happen out of the blue the best fixes tend to be:

1. Check/fix the clocks and NTP on both nodes
2. Wipe the DHCP database and let them rebuild it

It may have been stuck a while as they resynchronized their lease databases