dhcp shortcut addresses/entries?

Mystique_

dnsmasq has 0.0.0.0 which is uses to set the value to 'this interface' or 'this server'..

does isc/pfsense dhcp have anything like that?

Or if I want to set the ntp server to be myself I have to set it to the current interface via the IP..

For each ntp entry.. I would have to do the literal ip..

192.168.48.1, 172.16.48.1, 10.120.50.1, 10.120.63.1, 10.20.48.1, etc..

I have multiple devices, and trying to standardize on a basic config..

DNS says:
Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.

But that appears to ONLY be true for DNS..

johnpoz

@mystique_ so you want to hand each network of yours ntp, but the IP of the interface for that network.

Yeah pretty sure you have to add what ntp you want to hand out in dhcp server options. You could put in a feature request to have like a check mark to use the IP of the interface.

Keep in mind that not all clients will use that even if you hand it out.

Its prob best to validate on your clients what they are using for ntp.. Pretty sure for example windows doesn't honor ntp from dhcp. Unless they have changed something here really recent.

Mystique_

I was ultimately hoping to hijack the outbound udp/123 to local ntpd ..

Windows machines w/o AD have random time ntp states.. we store old machines and bring them out at random times for testing (school district..) so ultimately trying to get date and time valid for ssl certs and such..

Just wanted to see if there was a shortcut way to provide 'local' interfaces.. bunch of router swapping this summer.. migrating vlans, subnets, etc.. typos are productivity killers..

But looking for something that doesn't exist is also a vacuum..

Thanks in advance.

keyser

@mystique_ That’s very easy to do. Just create a destination NAT rule for UDP port 123 that forwards to 127.0.0.1.

That way all client requests are forwarded to your pfSense NTPD, and replies all comes from the same timesource.

johnpoz

@mystique_ yeah @keyser states you can intercept and redirect ntp traffic, just like you can do with dns.

But this only works for traffic that would hit pfsense, if your windows client for example is asking your AD which is on the same local network, pfsense would never see that traffic to redirect it to your ntp running on pfsense.

I intercept some ntp traffic for iot devices that freaking hard code what ntp server they talk to - F'ing bastards.. The one that ticks me off the most is some light bulbs that want to use the UK ntp pool.. Your not in the freaking UK you stupid iot device ;)

Mystique_

@keyser

I tried to do it w/ dns and couldn't get that right..

Figured I could interrupt ntp and no one would know..

But I've not been able to get the ntp hijack/intercept going..

I don't see where I tell where to map to (as you said loopback..)

I was thinking there would have to be some firewall rule in addition to a nat rule..

But all this does is allow ntp to be served..

Mystique_

@johnpoz

Yes no AD for these things, and ultimately dns hijack/intercept is the goal.. but I couldn't get that going..

Figured ntp would be easier to figure out and cause less interruption..

johnpoz

@mystique_ yeah you would need a firewall rule to go along with your port forward (interception)

And you would need to make sure ntp is actually listening on loopback (localhost/127.0.0.1) they all pretty much just different names for the same thing.. While loopback can be some other IP, normally when someone says loopback they mean the localhost address of 127.0.0.1

Common issue users have with dns, is they only pick tcp which I believe is default, but dns can be udp or tcp, normally udp.

And again you need to make sure your listing on the localhost interface, and yes you need a firewall rule.

keyser

@mystique_ said in dhcp shortcut addresses/entries?:

@johnpoz

Yes no AD for these things, and ultimately dns hijack/intercept is the goal.. but I couldn't get that going..

Figured ntp would be easier to figure out and cause less interruption..

There is no need to make outbound NAT rules and seperate firewall rules. Just create a NAT -> Port Forward rule and you are set (That creates the needed firewall rules automaticatlly).

Heres my rule:
PNG image.png

Mystique_

@johnpoz @keyser

So ty for the screenshot, I didn't have source advanced matched correctly..

And I was trying to redirect to another host..

so I am now seeing ntp clients on the router.. but of course (without physically going to each host..) I have another question..

pfsense host

 tcpdump -v -i igb0 dst port 123 and src net 10.20.0.0/16 -n -vvv

bare metal (void) linux host..

 tcpdump -v -i enp1s0f0.173 dst port 123 and src net 10.20.0.0/16 -n -vvv

What is up with all the time disparities?

1 and 4 look fine.. what is up with 2, 3, and 5?

The host on top is pfsense and running ntpd, host on bottom is running chronyd..

host 1 is another pfsense,
host 2 is a bare metal linux which locally reports correct time,
host 3 is an esxi vm also locally reporting correct time,
host 4 is an esxi windows vm locally reporting correct time,
host 5 is an axis camera locally reporting correct time..

I just wouldn't have expected to see all those different times..

This was the host I was testing from originally.. (which also looks correct locally and in the tcpdump..)

Random host had this to say about tcpdump timestamps..
(https://weberblog.net/packet-capture-network-time-protocol-ntp/)

"transmit timestamp: “Time at the server when the response left for the client.” This is the most interesting timestamp in those NTP packets since it shows the time the NTP client/server had as it sent the NTP packet. If you roughly want to know the time by looking at an NTP packet, look at this transmit timestamp."