NTP questions
-
Please bear with me if I say something stupid.
I was trying to check some things in ntp and I found this:
using ntpd command in my Mac, then doing "host 192.168.50.1", I can do lpeers, loppers or cv to my host. My network is like this:
modem -> pfsense -> lan (192.168.50.1)
-> vlan1 (10.1.2.1)
-> vlan2 (10.1.3.1)If I have ntp service in pfsense configured to listen on lan, vlan1 and vlan2, this is what loppers outputs in the mac that is connected to lan:
ntpq> lopeers
remote local st t when poll reach delay offset dispGPS_NMEA(0) 127.0.0.1 0 l - 16 0 0.000 0.000 15937.5
+ntp1.rrze.uni-e 10.1.3.1 1 u 40 64 1 82.664 33.731 187.528
*i2t15.i2t.ehu.e 10.1.3.1 1 u 39 64 1 59.477 33.190 187.529
-ntp.ring.nlnog. 10.1.3.1 1 u 38 64 1 73.991 27.088 187.532
+ntp1.nl.uu.net 10.1.3.1 1 u 37 64 1 64.211 33.186 187.530
-rackety.udel.ed 10.1.3.1 1 u 36 64 1 132.910 32.761 187.529If I listen only in lag and vlan1:
ntpq> lopeers
remote local st t when poll reach delay offset dispGPS_NMEA(0) 127.0.0.1 0 l 10 16 1 0.000 272.716 7937.75
+ntp1.rrze.uni-e 10.1.2.1 1 u 20 64 3 81.842 30.799 62.951
*i2t15.i2t.ehu.e 10.1.2.1 1 u 22 64 3 54.324 27.567 62.929
+ntp.ring.nlnog. 10.1.2.1 1 u 20 64 3 74.269 24.541 62.939
+ntp1.nl.uu.net 10.1.2.1 1 u 17 64 3 67.272 31.834 62.952
-rackety.udel.ed 10.1.2.1 1 u 16 64 3 130.222 31.014 62.951and finally only listening on lan:
ntpq> lopeers
remote local st t when poll reach delay offset dispGPS_NMEA(0) 127.0.0.1 0 l - 16 0 0.000 0.000 15937.5
+ntp1.rrze.uni-e 192.168.50.1 1 u 2 64 1 82.293 70.035 187.528
*i2t15.i2t.ehu.e 192.168.50.1 1 u 1 64 1 59.697 70.217 187.529
-ntp.ring.nlnog. 192.168.50.1 1 u 2 64 1 74.359 64.158 437.529
+ntp1.nl.uu.net 192.168.50.1 1 u 1 64 1 64.685 69.777 437.527
-rackety.udel.ed 192.168.50.1 1 u 2 64 1 128.318 67.617 937.523Shouldn't ntp service listen only in the lan interface? Mac is on lan. Why is pfsense routing thru other interfaces? I've tried to play with filter to see if it was some rule but it seems not to make a difference.
2.2-BETA (amd64)
built on Tue Dec 02 08:17:30 CST 2014
FreeBSD 10.1-RELEASE -
Looks right to me; what do you think is wrong?
The 'interface' lines in ntpd.conf control what the ntpd daemon listens to and responds to. The 'server' lines control what remote or local peers are consulted, as well as any local clock configurations.
-
Thanks for "stoping by". ;)
What seems wrong to me, is the fact that if my computer is querying on lan (192.168.50.1), why is it showing peers from another vlan ip? This happens just by allowing ntp to listen on these interfaces, not by changing rules. Do you think this is normal?
-
When using 'opeer' or 'lopeer', the local interface is printed, as opposed to the refid when using 'peer' or 'lpeer'.
In your 1st example, you allow lan, vlan1 and vlan2, and you see internet connections from vlan2 to time servers out on the 'net. In your last example, when you allow only lan, you see the connections only from your lan interface. See the srcadr and dstaddr in the data below.
Are you saying that vlan1 and vlan2 are configured to not allow internet access? Maybe I'm misunderstanding your question.
Detailed info using the 'association' command, and using 'rv' with the association number:
[2.2-BETA][root@pfsense.localdomain]/root: ntpq ntpq> pee remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .pps. 0 l 11 16 377 0.000 0.000 0.001 +watt.22pf.org 216.218.192.202 2 u 19 64 377 26.636 2.730 1.711 *0.time.dbsinet. 129.6.15.28 2 u 64 64 377 58.424 1.140 4.287 +2607:fa18:0:2:: 43.77.130.254 2 u 8 64 137 82.789 -0.332 2.003 ntpq> opee remote local st t when poll reach delay offset disp ============================================================================== oGPS_NMEA(0) 127.0.0.1 0 l 2 16 377 0.000 -0.001 0.232 +watt.22pf.org 192.168.2.128 2 u 26 64 377 26.636 2.730 4.569 +0.time.dbsinet. 192.168.2.128 2 u 4 64 377 53.365 -1.398 2.338 +2607:fa18:0:2:: _:66ff:fe6e:260 2 u 15 64 137 82.789 -0.332 2.171 ntpq> assoc ind assid status conf reach auth condition last_event cnt =========================================================== 1 31273 974a yes yes none pps.peer sys_peer 4 2 31274 9424 yes yes none candidate reachable 2 3 31275 9424 yes yes none candidate reachable 2 4 31276 9424 yes yes none candidate reachable 2 ntpq> rv 31274 associd=31274 status=9424 conf, reach, sel_candidate, 2 events, reachable, srcadr=watt.22pf.org, srcport=123, dstadr=192.168.2.128, dstport=123, leap=00, stratum=2, precision=-21, rootdelay=69.092, rootdisp=55.649, refid=216.218.192.202, reftime=d829a6ab.7f9e198f Wed, Dec 3 2014 10:11:39.498, rec=d829a6d1.870ae1c9 Wed, Dec 3 2014 10:12:17.527, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=15, flash=00 ok, keyid=0, offset=2.730, delay=26.636, dispersion=4.569, jitter=1.711, xleave=0.090, filtdelay= 31.44 30.40 27.40 28.44 27.50 28.42 26.64 27.67, filtoffset= 5.39 5.18 3.92 4.08 3.61 4.25 2.73 3.78, filtdisp= 0.00 0.98 1.95 2.91 3.90 4.91 5.91 6.90 ntpq> -
My problem is that using the same client,macbook on lan network, and issuing lopeers, the local interface changes as shown im my post. Maybe I'm just overlooking this but, shouldn't the client always see the ntp server on the interface where it is? If on lan, see lan ip. If on vlan1, see vlan1 interface.
-
But you are using the 'host' command. So even if you are typing ntpq inquiries on your mac client, you are really only querying ntpd on your pfSense machine. Results should be the same as if you ssh into your pfsense machine and use ntpq from there. In this case, pfsense is the client of time servers out on the net. If you want to use your mac as a client and query pfsense as a server, then simply do not use the host command.
I have no idea how ntpd picks which of the allowed interfaces is used for a connection, if that's what you mean. You allow lan, vlan1 and vlan2, and ntpd chooses vlan2. You allow lan and vlan1 only, then ntpd chooses vlan1. You allow only lan, and ntpd uses only lan. I don't see anything wrong.
-
Thanks, charliem. I've checked with 2.1.5 and it behaves exactly the same, so, it should be ok. Thanks again for taking the time to look at it.