Computers on a network are assigned unique numbers that they use to communicate with each other. We may think we went to www.ibm.com or \\somepc but, under the covers, numbers, not names, are used to identify devices on a network.

With the most common numbering scheme (IP version 4) some numbers are public and some are private. Private numbers are the greatest thing since sliced bread. Every home network can use the same set of private numbers safely because they are just that private; they are reserved for internal use only. These numbers will never, by definition, appear on the public Internet.

The numbers, of course, have a more techie name, they are called IP addresses. In the most common numbering scheme, IP addresses are written as four decimal numbers separated by periods (aka dots). A common private IP address is 192.168.1.1.

There are three groups of private IP addresses. One group are the IP addresses that start with 10. Another group are those that start with 192.168. These groups can be thought of as a neighborhood. Network nerds refer to a neighborhood as a subnet (short for sub network).

The neighborhood/subnet of numbers starting with 10 is a huge one allowing for millions of devices. For home use, routers typically use a smaller neighborhood, such as the one starting with 192.168.1 which only allows for 253 devices. All the devices connected to the router will have an IP address that starts with 192.168.1. If you use a Google WiFi router, then all your devices have numbers that start with 192.168.86. If you use Peplink, the default subnet/neighborhood is 192.168.50.

Generally, devices communicate either with the public Internet or with other devices connected to the same router. You would think this covers all the bases, but no. This blog is about a third alternative, devices that try to communicate to private IP addresses on the public Internet.

You might think that a router is smart enough not to allow this, but that has not been my experience. Routers typically treat the subnet/neighborhood that they Lord Over as their private area and everything else as being the outside world. So, if a device connected to a Google router, one that has an IP address starting with 192.168.86 tries to communicate with a device at IP address 10.1.2.3, routers (in my experience) just send that request out their WAN port to the Internet.

What the heck?

The big routers at your ISP and on the Internet backbone are supposed to drop any packets targeted at private IP addresses.

In one case that I know of, it makes sense to send a request for a private IP address out the WAN port of a router: when an Internet connection consists of a router and a modem as separate devices.

Many modems use 192.168.100.1 as their IP address. So, if you want to see the web interface of the modem, you could enter this IP address in the address bar of a web browser. This HTTP request leaves the router destined for the Internet, but it gets intercepted by the modem. I wrote about this back in 2015: Talk to your modem.

Firewall Rules for Private IP Addresses

Long ago I decided to crack down. The firewall rules shown above block anything leaving the router (a Pepwave Surf SOHO) targeted at a private IP address. These three rules block the three groups of private IP addresses. And, they make a log entry when they do so. The Surf SOHO is a business class router, as a rule consumer routers are not able to create outbound firewall rules.

For months now, I have seen quite a lot of computers trying to phone home to internal IP address on the Internet. I can not explain why.

Below is one example, of many. It is an edited excerpt from the router log file. The Windows 7 computer with IP address 10.1.2.3 lives in a subnet where all the devices have IP addresses that start with 10.1.2. Yet over the span of six seconds, it made seven attempts to communicate with a device having a private IP address of 192.168.0.4. Specifically, it tried to communicate using UDP to a high numbered destination port (SRC is the Source IP address, DST is the Destination IP address, PROTO is the Protocol, either TCP or UDP, SPT is Source Port, DPT is Destination Port). Quite suspicious.

09:20:33 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8531 PROTO=UDP SPT=62208 DPT=52421
09:20:30 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8380 PROTO=UDP SPT=62208 DPT=52421
09:20:28 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8302 PROTO=UDP SPT=62208 DPT=52421
09:20:27 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8263 PROTO=UDP SPT=62208 DPT=52421
09:20:27 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8231 PROTO=UDP SPT=62208 DPT=52421
09:20:27 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8220 PROTO=UDP SPT=62208 DPT=52421
09:20:27 Denied SRC=10.1.2.3 DST=192.168.0.4 ID=8214 PROTO=UDP SPT=62208 DPT=52421

Interleaved with this, were other requests to the private IP address 10.8.0.11 also using UDP to a high numbered port.

09:20:32 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8483 PROTO=UDP SPT=62204 DPT=55523
09:20:29 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8323 PROTO=UDP SPT=62204 DPT=55523
09:20:27 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8233 PROTO=UDP SPT=62204 DPT=55523
09:20:26 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8187 PROTO=UDP SPT=62204 DPT=55523
09:20:26 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8166 PROTO=UDP SPT=62204 DPT=55523
09:20:26 Denied SRC=10.1.2.3 DST=10.8.0.11 ID=8155 PROTO=UDP SPT=62204 DPT=55523

To repeat myself, I have no idea why this happened. But, if I worked for a spy agency, this is exactly what I would do.

These data packets would normally get transmitted to the ISP, who should throw them away. But what if ... the ISP was assisting a spy agency?

What if these packets were not thrown away? What if these transmissions were from a compromised device phoning home? If so, what better way to ex-filtrate data then to send it to the ISP and only to the ISP. It is certainly possible for an ISP to send all data destined to a specific private IP address off to the side to be collected by an agency of the government they work under.

Again, this is a total guess on my part.

What else might explain this network traffic?

It is unlikely to be malware trying to spread because it is not trying to contact devices on its own subnet (10.1.2.x). Malware that did spread on the local subnet would not have been flagged by my three firewall rules.

It could be a programming oversight. Perhaps some piece of software was not correctly modified or upgraded when it was publicly released and it is still trying to contact something on the LAN where it was originally developed. I discount this because I have seen this happen too often and in too many different patterns for that to be the case.

For example, a Windows computer was originally on the 192.168.1.x subnet which had a NAS device at IP address 192.168.1.2. Months after moving the computer to new location and a new subnet (10.1.2.x) it still tries to do Windows File Sharing to the NAS at 192.168.1.2. Specifically, it tries to open TCP connections to ports 445 and 139. Even stranger, it opens TCP connections to high numbered ports at 192.168.1.104, an IP address that was never used for anything back when it was on the 192.168.1.x subnet.

Soon, I hope to write up the details of iOS devices that make outbound requests to TCP port 7000 on private IP address in subnets other than their own.

The strange requests happen perhaps once a day on the routers I watch over. Not frequent enough for me to sniff all the packets on the LAN and go back later to see what the data being sent was. Even then, the data may have simply been the start of handshake with the good stuff to follow later. I suppose I could disable the firewall rules, let the strange data flow while still logging it to look for patterns. But this is where I draw the line. We all have limited amounts of time.

I have to wonder though, if private IP addresses are the next generation of spying? Any spy agency would reasonably expect this type of data transmission to fly under the radar. At least, most of the time.