The problem/limitation is probably from local port binding of the client:123 which is used for both connections.
I see other clients that use high ports for ntp queries that create multiple states without any problem. all udp 127.0.0.1:123 (remote_ntp1:123) <- y.y.y.y:54401 SINGLE:MULTIPLE all udp 127.0.0.1:123 (remote_ntp2:123) <- y.y.y.y:52525 SINGLE:MULTIPLE :( G On 15/09/2022 11:12, Kapetanakis Giannis wrote: > Hi, > > I'm trying to enforce a local ntpd server (which is also our external > firewall/router) for all connections and I have a very strange problem. > Only one (dst) IP is allowed to create a state. After state expires a new dst > IP can be used. > > fw# pfctl -sr -R 154 > pass in log quick on $int_if inet proto udp from x.x.x.x to any port = 123 > rdr-to 127.0.0.1 > > client-x-x-x-x# ntpdate 1.2.3.4 > 15 Sep 10:34:15 ntpdate[620]: adjust time server 1.2.3.4 offset -0.000096 sec > > On fw (ntpd server) I see: > > 10:34:09.366370 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:09.366460 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > 10:34:11.366247 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:11.366281 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > 10:34:13.366275 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:13.366324 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > > Sep 15 10:34:09.366383 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > > # pfctl -ss -vv -R 154 > > all udp 127.0.0.1:123 (1.2.3.4:123) <- x.x.x.x:123 MULTIPLE:MULTIPLE > age 00:00:19, expires in 00:00:47, 4:4 pkts, 304:304 bytes, rule 154 > id: 628ba534a943cb3c creatorid: 00000001 > > Subsequent ntp queries to same IP 1.2.3.4 work fine. Same state is used. pkts > advance, expire time resets to 60 seconds > > However if I try a different dst IP from the same client it does not work > until state to 1.2.3.4 above expires. > > I see the incoming packet on the internal interface but I see no reply going > back to client (as before with 1.2.3.4). > > 10:34:26.812675 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:28.812571 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:30.812587 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:32.812554 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > > I also see the pf log (4 times now and not 1 as before) > Sep 15 10:34:26.812688 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:28.812583 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:30.812598 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:32.812566 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > > No new state is created. pfctl -ss -R 154 only lists the one state of 1.2.3.4 > > After state expiration, a different IP can be used and works. > > Initial pf rule included keep state (max-src-states 10, source-track rule) > which also behaves the same. 10 src-IP connections are allowed and then no > more until one is expired. > However, again, if another destination IP is used I see no replies (bellow > the src limit of 10). > > system is 7.1 amd64 which syspatches. > > ntpd only lists servers, constraints and > listen on 127.0.0.1 > listen on ::1 > > ideas? > > G > > > >
