ntpMerlin Does ntpMerlin redirect local NTP-queries?

[archiel]

Following up - after switching to chrony I am seeing the same behaviour as with ntp

On a windows machine with internet time server set to time.windows.com I hit Update Now
I can see the updated counts in both serverstats and client, but looking at the packet data the the client-server conversation is clearly between the windows machine and time.windows.com - there is no sign of the gateway being involved.

I then changed the internet time server on the windows machine to point at the gateway and ran Update Now
As before I can see the updated counts in both serverstats and client, but now looking at the packet data the the client-server conversation is clearly between the windows machine and the gateway address (chrony).

While I do not pretend to know the details of what is happening under the hood and I may have completely misunderstood how ntp / chrony are meant to work as servers, to me it looks as if

• ntpmerlin succesfully runs both ntp and chrony as clients for the router
• (on my setup) neither ntp not chrony act as servers unless the local client is explicitly pointed at the gateway

The next step is to uninstall ntpmerlin and see what happens using the built in ntp enabled and set to server mode.

 

[archiel]

@RMerlin Would you please assist

It seems to me that 'Intercept client NTP requests' is not working. The reason I think this is from looking at the output of tcpdump on port 123, I can see client-server NTP conversations between the local devices on the network and external NTP servers (not specified in the Administration screen, ntp.conf or crony.conf).

(Almost) the only time I see client-server NTP conversations between local devices and the local NTP server (i.e. the gateway address) is if I have manually set the NTP server address (on the client) to the LAN gateway.

I get the same behaviour with ntpMerlin (ntp and chrony) and without (after uninstalling ntpMerlin and rebooting) with setting the NTP server in Administration to

Enable local NTP server : Yes
Intercept NTP client requests: Yes

and checking

nvram show 2>/dev/null | grep ntpd_
ntpd_enable=1
ntpd_server_redir=1

The router was fully reset after updating to 386.1_2 and all settings entered manually, so I do not think any carried over code (from 384.19) would be there

What I am trying to get to is whether

1. Interception is working, but I do not understand the tcpdump output I am looking at, or
2. It is not working due to the firmware on the router, or
3. it is not working due to the particular scripts I have on the router (as listed in my signature, but ntpMerlin removed for testing)

If it is 2 or 3, then I will probably need to leave this until I update to the release version of 386.2, when I can start with testing on a fully reset device (nothing added other than entware and tcpdump) and adding scripts and settings one-at-at-time (doing a full rebuild takes me most of a day and during lockdown doing this for anything less than a new version is not practical)

Thank you

 

[EmeraldDeer]

Are you sure you are running chrony as a server to your LAN? Note the allow, bindaddress and binddevice lines in my chrony.conf.

allow 192.168.50.0/24
bindaddress 192.168.50.1
binddevice br0
driftfile /opt/var/lib/chrony/drift
dumpdir /opt/var/lib/chrony
dumponexit
lock_all
logchange 0.1
makestep 1.0 3
pidfile /opt/var/run/chrony/chronyd.pid
pool time.apple.com
pool time.cloudflare.com
pool time.nist.gov
server 192.168.50.230 iburst minpoll 3 maxpoll 3 xleave

 

[EmeraldDeer]

Use netstat to determine whether chronyd is listening.

# netstat -anp | grep ':123'
udp        0      0 192.168.50.1:123        0.0.0.0:*                           4146/chronyd

 

[archiel]

Use netstat to determine whether chronyd is listening.

# netstat -anp | grep ':123'
udp        0      0 192.168.50.1:123        0.0.0.0:*                           4146/chronyd

I have reverted to chrony and using the above I just get

netstat -anp | grep ':123'
udp        0      0 0.0.0.0:123             0.0.0.0:*                           8411/chronyd

It should also be noted that the chrony.conf file created by ntpMerlin (on my system) does not set either of bindaddress or binddevice

I tried adding these manually, but I still see the client-server conversations taking place between the local device and the external server. IOW, chrony (or NTP), may be listening on 123, but it doesn't seem to me that it is acting as the server when a request is issued.

 

[EmeraldDeer]

I may be wrong and chronyd listens just fine out of the ntpMerlin box. I had not not noticed it listening and I wanted to be sure that it was only listening on the LAN side anyway.

A while back I noticed from time to time that the NTP client interception would stop working. After disabling and enabling, it was back. But this has not been a problem for a long time.

 

[heysoundude]

The redirect rule for ipv6 would point at the respective Lan ipv6 address associated with the router. Just as the ipv4 redirect points at the ipv4 Lan address. The problem is that the router ip/nat tables does not support redirect as an option for ipv6. The same applies with dns filter redirects, it only supports ipv4. That is why it is suggested to block ipv6 because otherwise it will leak. For devices that prefer ipv6 over ipv4, Your local ntp server may be skipped all together defeating the purpose of using a local ntp server because the request will leak via ipv6.

ugh.
It's going to be some time yet before IPv4 goes the way of the dinosaur, so what's required is a bridge of some sort: Jool
this is WAAAY out of my depth, but the (Cisco certified) person who turned me on to ipv6 and hurricane electric pointed me in this direction too. With any luck, someone reading this here will get inspired to figure out how to make it work for us Merlinites. And yeah, I think it will be a Merlin-specific solution, because of all of the scripts we like to use...my guess is that Asus would tell us we're on our own too, for the time being, until they decide they need to bake it into theirs.

 

[SomeWhereOverTheRainBow]

@RMerlin Would you please assist

It seems to me that 'Intercept client NTP requests' is not working. The reason I think this is from looking at the output of tcpdump on port 123, I can see client-server NTP conversations between the local devices on the network and external NTP servers (not specified in the Administration screen, ntp.conf or crony.conf).

(Almost) the only time I see client-server NTP conversations between local devices and the local NTP server (i.e. the gateway address) is if I have manually set the NTP server address (on the client) to the LAN gateway.

I get the same behaviour with ntpMerlin (ntp and chrony) and without (after uninstalling ntpMerlin and rebooting) with setting the NTP server in Administration to

Enable local NTP server : Yes
Intercept NTP client requests: Yes

and checking

nvram show 2>/dev/null | grep ntpd_
ntpd_enable=1
ntpd_server_redir=1

The router was fully reset after updating to 386.1_2 and all settings entered manually, so I do not think any carried over code (from 384.19) would be there

What I am trying to get to is whether

1. Interception is working, but I do not understand the tcpdump output I am looking at, or
2. It is not working due to the firmware on the router, or
3. it is not working due to the particular scripts I have on the router (as listed in my signature, but ntpMerlin removed for testing)

If it is 2 or 3, then I will probably need to leave this until I update to the release version of 386.2, when I can start with testing on a fully reset device (nothing added other than entware and tcpdump) and adding scripts and settings one-at-at-time (doing a full rebuild takes me most of a day and during lockdown doing this for anything less than a new version is not practical)

Thank you

The problem with using wireshark to interpret the data, You are missing the other end of the perspective. Wireshark will only see the request, it does not know that under the hood the traffic is being intercepted and sent back to your lan address. It assumes the responses are coming from the server that the time request is sent to and knows no different. The other part of the package is on your connections tab under system log...
observe.

This shows the ntp request of my windows device pointed at the router

The wireshark inspection only shows half the story.

it shows a request made to time.windows.com.

But the router connection page shows it is intercepted to my lan address(the true ntp server).

This is enforced by these rules:

The problem is, there is masquerading involved, so wireshark thinks the response is coming from the time.windows.com instead of the lan address.

I don't know if there is a proper way to use IP tables to make wireshark get the correct information.

To properly see the interaction happening, you need to log packets for port 123 using IPTables.

 

[archiel]

The problem with using wireshark to interpret the data, You are missing the other end of the perspective. Wireshark will only see the request, it does not know that under the hood the traffic is being intercepted and sent back to your lan address. It assumes the responses are coming from the server that the time request is sent to and knows no different. The other part of the package is on your connections tab under system log...
observe.

View attachment 32325

This shows the ntp request of my windows device pointed at the router

View attachment 32326

The wireshark inspection only shows half the story.

it shows a request made to time.windows.com.

But the router connection page shows it is intercepted to my lan address(the true ntp server).

This is enforced by these rules:

View attachment 32327


The problem is, there is masquerading involved, so wireshark thinks the response is coming from the time.windows.com instead of the lan address.

I don't know if there is a proper way to use IP tables to make wireshark get the correct information.

To properly see the interaction happening, you need to log packets for port 123 using IPTables.

As, you suggest, it may well be the masquerading that is hiding the underlying processes, but most of the time I am not seeing the the expected entries in Connections.

How would I setup the logging using IPTables to investigate this further?

 

[EmeraldDeer]

I logged in to two PuTTY sessions on the router. In one screen, a tcpdump of the WAN interface port 123. On the other screen, a tcpdump of the LAN interface port 123. Sure enough, LAN devices appear to request NTP from external servers but there is no corresponding traffic on the WAN side. My conclusion is that redirection is working. I think the redirected requests open and close too quickly to be caught in the Connections tab.

 

[MvW]

I logged in to two PuTTY sessions on the router. In one screen, a tcpdump of the WAN interface port 123. On the other screen, a tcpdump of the LAN interface port 123. Sure enough, LAN devices appear to request NTP from external servers but there is no corresponding traffic on the WAN side. My conclusion is that redirection is working. I think the redirected requests open and close too quickly to be caught in the Connections tab.

I installed tcpdump. Would you be so kind to share the commands you used for your experiment? I'm not familiar with the use of tcpdump but eager to learn.

Thanks in advance.

Best regards,
Marco

 

[EmeraldDeer]

I installed tcpdump. Would you be so kind to share the commands you used for your experiment? I'm not familiar with the use of tcpdump but eager to learn.

Thanks in advance.

Best regards,
Marco

On my router eth0 is WAN and br0 is LAN

tcpdump -c 100 -i eth0 port 123
tcpdump -c 100 -i br0 port 123

 

[MvW]

On my router eth0 is WAN and br0 is LAN

Thanks, much appreciated! How can I check on my RT-AC86U which interface is representing LAN and which is the WAN interface?

 

[EmeraldDeer]

Thanks, much appreciated! How can I check on my RT-AC86U which interface is representing LAN and which is the WAN interface?

Run ifconfig -a. Look for the interfaces configured with your LAN subnet and your WAN IP.

 

[SomeWhereOverTheRainBow]

Run ifconfig -a. Look for the interfaces configured with your LAN subnet and your WAN IP.

I see tcpdump as one tool for observing the traffic, but to see the redirection in action, it would be nice to log the packets on port 123 with iptable logging.

 

[archiel]

I see tcpdump as one tool for observing the traffic, but to see the redirection in action, it would be nice to log the packets on port 123 with iptable logging.

How can i do that?

 

[SomeWhereOverTheRainBow]

How can i do that?

I was hoping by now someone with IP table knowledge would shed some light on how to log traffic on port 123. It is doable, I am not sure how it is done on the older kernals used by asus though.

 

[Maverickcdn]

I was hoping by now someone with IP table knowledge would shed some light on how to log traffic on port 123. It is doable, I am not sure how it is done on the older kernals used by asus though.

You log connections with IPTABLES using logdrop or logaccept... so maybe something like

iptables -I FORWARD -p udp --dport 123 -j logaccept
iptables -I FORWARD -p udp --sport 123 -j logaccept

Id think'd youd need to use the INPUT/OUTPUT chains if trying to capture the Router send/receive on port 123, or maybe specify an interface? Not 100% myself... I just know logging of IPTABLES rules is an option

 

[SomeWhereOverTheRainBow]

You log connections with IPTABLES using logdrop or logaccept... so maybe something like

iptables -I FORWARD -p udp --dport 123 -j logaccept
iptables -I FORWARD -p udp --sport 123 -j logaccept

Id think'd youd need to use the INPUT/OUTPUT chains if trying to capture the Router send/receive on port 123, or maybe specify an interface? Not 100% myself... I just know logging of IPTABLES rules is an option

you would need prerouting chain as well

 

[SomeWhereOverTheRainBow]

watch -n 5 -t 'iptables -nvL -t nat | grep "123"'

this will let you see the packet count increase of the packets that get routed to the local ntp server. it refreshes in 5 second intervals.