Recently, I installed a new AmpliFi mesh system in the home of a relative. Back home, I decided to check for any open WAN (Internet) side ports on the router, so I ran a normal plain vanilla nmap port probe, nmap 1.2.3.4, where 1.2.3.4 is the public IP address of the AmpliFi router. This scans 1,000 TCP (no UDP) ports.

Any router purchased at retail (as opposed to one provided by an ISP) should be expected to have all these ports closed. Nmap can do much more, this is merely a first step.

Surprisingly, the AmpliFi router had TCP port 53, used for DNS, open. I emailed their tech support and got no reply. A week later, I emailed again and got some disappointing responses. Basically, Ubiquiti (which manufactures the AmpliFi line of mesh routers) said that this was normal. They pointed me to an irrelevant web page as proof, a page that discussed a Linux desktop machine (not a router) and port 53 being open on the LAN side (not the WAN side). Then, they stopped responding altogether.

Just as disappointing as their response was what they did not try to do. I gave AmpliFi the public IP address of the router in question, you would think they would try to confirm my nmap results. But no.

While waiting on AmpliFi, I decided to run the same nmap port probe on three Peplink routers for which I do the care and feeding. Each one reported that TCP port 53 was open on the WAN side. This struck me as strange since the last time I checked the WAN ports they were all closed. I do this when a router is new and I do it on my LAN rather than the Internet.

AmpliFi is a consumer router, and thus offers tech support which is par for the course with consumer routers. Peplink, on the other hand, is geared to professionals. The router I recommend on my RouterSecurity.org site, is their cheapest model ($200) the Pepwave Surf SOHO. If you have to ask the price of their more powerful routers, you can't afford it. The Surf SOHO is like driving the cheapest Porsche. It's still a Porsche.

A huge advantage of having Peplink router is their excellent tech support. Their tech support person tried the same nmap probe with different results. Heck, I tried the same nmap probe the next day and also got different results; TCP port 53 was closed on all three Peplink routers. Did I hallucinate?

Peplink suggested that port 53 was special. Unlike all other ports, the DNS port is sometimes proxied and intercepted before the router sees the port probe.

This sounded plausible. I normally use a VPN and often switch the VPN server that I connect to. So, it could be, that from one location, port 53 was being intercepted but that from another location it was not.

But, how to prove it?

One advantage of driving a Porsche are the features they have that lesser cars do not. In my case, my Porsche, the Peplink router, has a feature that is, to a networking nerd, way cool: it can run a packet capture on its own. That is, it can record every bit and byte coming and going and save this transmission log in the router itself. No command line needed. Even better, it can do this while being remotely controlled. Still better, I can then download the captured log to my computer. Wow.

Learning to read a packet capture can take a very long time. But I knew what I was looking for and Wireshark is a great help.

I started with an nmap port probe of 4 ports, one below the one that I new was open, the open port and two above it. The command looked something like nmap -p 303-306 1.2.3.4 where I new that port 304 was open and 1.2.3.4 is the public IP address of a Peplink router. You can see part of the result below.

nmap port probes as seen by Wireshark

We first see four data packets coming in from port 64771 to the target ports. The nmap port probes are SYN packets. The first three generate no response. The last one, the one with a port number ending in 4, generated a SYN, ACK packet in response.

Now that I knew what to look for, I did a port probe for ports 52, 53 and 54. Specifically, this: nmap -p 52-54 1.2.3.4

nmap port probes as seen by Wireshark - No port 53

Shown above, the first probes were 9.24 seconds after the packet trace started. We see incoming requests to ports 52 and 54 but not 53.

nmap port probes re-tried a second time

Since there was no response, nmap made second requests, shown above, 10.37 seconds after the packet trace had started. As before, we see only two probes, to ports 52 and 54. The source port the second time was 45611, the first time it was 45610.

This is the smoking gun. Definitive proof that what Peplink speculated was, in fact, the case. Someone was intercepting the nmap probes to port 53 and nmap never got to talk to the router.

While it is not fair to say that nmap, in the screen shot below, is lying to us, the results are nonetheless wrong. The router being probed has TCP port 53 closed on the WAN side.

A false positive on WAN side TCP Port 53

Why this happens is beyond me.

Update. Oct 27, 2019: According to David Redekop: "Ask any ISP network admin and they will tell you. NTP (port 123) and DNS are targets for UDP amplification attacks. Rarely do ISP subscribers need public facing DNS or NTP connections. It is wise for ISPs to intercept and answer/protect such queries which yields your experience."

Twitter users can comment on this here.