Connection Tracing

I’m using https-dns-proxy to hijack plaintext DNS requests and redirect them to DoH (DNS-over-HTTPS).

I’ve enabled the built-in NTP (time) server in the OpenWRT One:

System >> System >> Time Synchronization tab:

Enable NTP Client: checked
Provide NTP Server: checked
Bind NTP Server: lan
Use DHCP Advertised servers: unchecked

I set up some firewall rules to prevent DNS leaks, and to force NTP clock synchronization through the OpenWRT One’s NTP server, and wanted a way to trace how they were working.

Firewall - Traffic Rules:

Reject-Router-To-Wan (Port 53, 853) | Outgoing IPv4 and IPv6 | From this device | To wan, port 53, 853 | Reject output

Drop-Router-To-Wan (Port 5353) | Outgoing IPv4 and IPv6, protocol UDP | From this device | To wan, port 5353 | Drop output

Reject-LAN-To-Wan (Port 53, 853) | Forwarded IPv4 and IPv6 | From lan | To wan, port 53, 853 | Reject forward

Drop-LAN-To-Wan (Port 5353) | Forwarded IPv4 and IPv6, protocol UDP | From lan | To wan, port 5353 | Drop forward

Drop-WAN-To-Router (Port 53, 853) | Incoming IPv4 and IPv6, protocol TCP, UDP | From wan | To this device, port 53, 853 | Drop input

Port 53 is plaintext DNS
Port 853 is secure DNS
Port 5353 is mDNS.

Firewall - Port Forwards:

Redirect-Lan-NTP-IPv4 (Port 123) | Incoming IPv4, protocol UDP | From lan | To this device, port 123 | Forward to lan IP 192.168.1.1 port 123

Redirect-Lan-NTP-IPv6 (Port 123) | Incoming IPv6, protocol UDP | From lan | To this device, port 123 | Forward to lan IP fe80::2205:b6ff:fe02:23b1 port 123

192.168.1.1 is OpenWrt.lan
fe80::2205:b6ff:fe02:23b1 is OpenWrt.lan

Ensure you have the nftables-json package installed.

Inject a target tracking rule directly into the kernel mangle-prerouting array:

nft insert rule inet fw4 mangle_prerouting tcp dport { 53, 853, 5353 } meta nftrace set 1
nft insert rule inet fw4 mangle_prerouting udp dport { 53, 853, 5353 } meta nftrace set 1

That injects those rules into volatile kernel memory. Those rules won’t survive a firewall reload nor a router reboot.

And we’ll start monitoring, in a Terminal window connected to the OpenWRT One router via DropBear ssh (ssh [email protected], enter root password):

nft monitor trace

If you don’t set any nft insert rule inet fw4 mangle_prerouting rules, nft monitor trace will just sit there, outputting nothing.

I triggered my cellphone’s podcast app to search for new episodes.

One such transaction which was captured:

trace id 7e02519b inet fw4 mangle_input policy accept

trace id 7e02519b inet fw4 input packet: iif “br-lan” ether saddr 96:55:4e:61:19:20 ether daddr 20:05:b6:02:23:b1 ip6 saddr fdd3:817b:b8b5:0:b99e:a3b2:572:65ab ip6 daddr 2601:2c1:947f:48c2::1 ip6 dscp cs0 ip6 ecn not-ect ip6 hoplimit 64 ip6 flowlabel 345956 ip6 nexthdr udp ip6 length 46 udp sport 9228 udp dport 53 udp length 46 udp checksum 2604

trace id 7e02519b inet fw4 input rule iifname “br-lan” jump input_lan comment “!fw4: Handle lan IPv4/IPv6 input traffic” (verdict jump input_lan)

trace id 7e02519b inet fw4 input_lan rule ct status dnat accept comment “!fw4: Accept port redirections” (verdict accept)

The cellphone running the podcast app (ether saddr 96:55:4e:61:19:20) has an IPv6 address of fdd3:817b:b8b5:0:b99e:a3b2:572:65ab.

The podcast app checked for new episodes while using a plaintext DNS lookup over UDP Port 53 (udp dport 53).

https-dns-proxy, however, hijacked that plaintext DNS request, sending it out over DoH.

Line 1 (mangle_input): The packet clears the basic packet-mangling checks safely (policy accept).

Line 2 (input packet): The hardware interface (br-lan) reads the raw metadata of the incoming UDP/53 packet.

Line 3 (input_lan jump): The firewall recognizes the traffic is coming in from the local network interface and jumps it into the specific LAN chain (jump input_lan).

Line 4 (verdict accept): The packet hits this rule: rule ct status dnat accept comment “!fw4: Accept port redirections”

The firewall analyzed the packet, saw that its connection tracking (ct) state was flagged as a hijacked local port redirection, and said: “This packet was successfully overridden by the administrator’s proxy rule. Accept it and hand it straight to https-dns-proxy.”

Let’s clear the nft insert rule inet fw4 mangle_prerouting rules:

fw4 reload

Now we’ll do the same sort of tracing for NTP clock synchronization…

nft insert rule inet fw4 mangle_prerouting udp dport { 123 } meta nftrace set 1

And we’ll start monitoring, in a Terminal window connected to the OpenWRT One router via DropBear ssh (ssh [email protected], enter root password):

nft monitor trace

I triggered my Windows computer to do a time sync.

Here’s the full chain for one trace id:

trace id f564bdab inet fw4 mangle_prerouting packet: iif “br-lan” ether saddr f8:89:d2:87:fe:d9 ether daddr 20:05:b6:02:23:b1 ip saddr 192.168.1.143 ip daddr 40.119.6.228 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 56447 ip protocol udp ip length 76 udp sport 123 udp dport 123 udp length 56 udp checksum 46281

trace id f564bdab inet fw4 mangle_prerouting rule udp dport 123 meta nftrace set 1 (verdict continue)

trace id f564bdab inet fw4 mangle_prerouting policy accept

trace id f564bdab inet fw4 dstnat packet: iif “br-lan” ether saddr f8:89:d2:87:fe:d9 ether daddr 20:05:b6:02:23:b1 ip saddr 192.168.1.143 ip daddr 40.119.6.228 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 56447 ip protocol udp ip length 76 udp sport 123 udp dport 123 udp length 56 udp checksum 46281

trace id f564bdab inet fw4 dstnat rule iifname “br-lan” jump dstnat_lan comment “!fw4: Handle lan IPv4/IPv6 dstnat traffic” (verdict jump dstnat_lan)

trace id f564bdab inet fw4 dstnat_lan rule meta nfproto ipv4 udp dport 123 counter packets 0 bytes 0 dnat ip to 192.168.1.1:123 comment “!fw4: Redirect-Lan-NTP-IPv4 (Port 123)” (verdict accept)

trace id f564bdab inet fw4 prerouting packet: iif “br-lan” ether saddr f8:89:d2:87:fe:d9 ether daddr 20:05:b6:02:23:b1 ip saddr 192.168.1.143 ip daddr 192.168.1.1 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 56447 ip protocol udp ip length 76 udp sport 123 udp dport 123 udp length 56 udp checksum 8827

trace id f564bdab inet fw4 prerouting rule iifname “br-lan” jump helper_lan comment “!fw4: Handle lan IPv4/IPv6 helper assignment” (verdict jump helper_lan)

trace id f564bdab inet fw4 prerouting policy accept

trace id f564bdab inet fw4 mangle_input packet: iif “br-lan” ether saddr f8:89:d2:87:fe:d9 ether daddr 20:05:b6:02:23:b1 ip saddr 192.168.1.143 ip daddr 192.168.1.1 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 56447 ip protocol udp ip length 76 udp sport 123 udp dport 123 udp length 56 udp checksum 8827

trace id f564bdab inet fw4 mangle_input policy accept

trace id f564bdab inet fw4 input packet: iif “br-lan” ether saddr f8:89:d2:87:fe:d9 ether daddr 20:05:b6:02:23:b1 ip saddr 192.168.1.143 ip daddr 192.168.1.1 ip dscp cs0 ip ecn not-ect ip ttl 128 ip id 56447 ip protocol udp ip length 76 udp sport 123 udp dport 123 udp length 56 udp checksum 8827

trace id f564bdab inet fw4 input rule iifname “br-lan” jump input_lan comment “!fw4: Handle lan IPv4/IPv6 input traffic” (verdict jump input_lan)

trace id f564bdab inet fw4 input_lan rule ct status dnat accept comment “!fw4: Accept port redirections” (verdict accept)

The Device: A Windows machine with IP 192.168.1.143 (ether saddr f8:89:d2:87:fe:d9), reaching out to a Microsoft-owned public NTP time server over the internet (40.119.6.228) [•].

The Target: It emits a UDP packet originating from Source Port 123, heading toward Destination Port 123 (udp dport 123).

Line 2 (mangle_prerouting): The packet passes the temporary testing hook we set (udp dport 123 meta nftrace set 1). The kernel tags it with an internal tracking ID (f564bdab) so it can be traced.

Line 4 & 5 (dstnat_lan): The packet arrives at the firewall routing hooks with its original public destination address (ip daddr 40.119.6.228).

Line 6 (Redirect-Lan-NTP-IPv4 (Port 123)): The packet matches the port-forward rule:dnat ip to 192.168.1.1:123 comment “!fw4: Redirect-Lan-NTP-IPv4 (Port 123)” (verdict accept)

Line 7 (prerouting): The destination IP address has been changed from the public Microsoft server (40.119.6.228) to the router’s local LAN gateway IP: ip daddr 192.168.1.1.

Line 8-11: The router’s Connection Tracking Helpers (ct helpers) jump the packet into helper_lan, which ‘mangles’ the packet so it’s redirected to 192.168.1.1.

Line 12-13 (input_lan): The packet arrives at the internal local network security checks.

Line 14: The packet hits this rule: rule ct status dnat accept comment “!fw4: Accept port redirections” (verdict accept)

The packet is safely delivered directly to OpenWRT’s local ntpd time server.

The Windows computer believes it communicated with a Microsoft-owned public NTP time server at IP address 40.119.6.228, when really it communicated with the OpenWRT ntpd time server.

Let’s clear the nft insert rule inet fw4 mangle_prerouting rules:

fw4 reload

And that is how you can trace connections on your own network.