'Random' Traffic from FW to Internet

[OppyOppy]

I am wondering what the 'random' and seemingly constant flow of trafffic from my f/w to the internet is...
I understand the destination of 8.8.8.8 and port 53, and I can understand a packet with a destination port of 443, but the overall sense that I get is that there's something INSIDE my network that is chatting away.  The network is used by my wife and I.  I do have a few devices on the network - several Apple TVs, a PS4, a Macbook or two, a PC or two, and several WAPs (Netgear R7000 running DD-WRT).

Please see the attached file as I could not figure out how to embed an image in the post. :-(

[meyergru]

Many IoT and multimedia devices (including smartphones) "phone home". That is why I separate them from my other devices in an IoT VLAN.

Port 443 is HTTPS traffic and you can lookup the IPs via https://ipinfo.io/ to see which target network is being accessed. Those connections can be anything from cloud services to auto-updates. You can also inspect your log  entries in order to see which client(s) cause the traffic in question.

Also, you could block outgoing traffic for specific clients one after the next to have a separate log messages that you can chase down further.

[OppyOppy]

Many thanks Meyergru.  I should definitely isloate the IoT devices.

[Seimus]

@meyergru
thanks for that page, its awesome no clue how i missed it when I tried to find a good page to identify IPs.

@rkoftan
Its definitely a IoT device. I have seen this on my network as well. A lot of devices even if their DNS was set for my PiHole wanted to chat and preferred google. Additional to that some IoT devices tried to communicate with wierd destinations.

I am keeping IoT on separate isolated VLAN, this VLAN can not access anything on LAN. Only devices on LAN can access IoT. My IoT network was completely isolated and using live capture only necessary Destination and Ports were for IoT allowed as for example reach to cloud services for Updates etc. Its a bit painful and manual process, but it gives you the possibility to prevent the IoT devices from communicating to random crap and keep their functionality.

Regards,
S.

[Seimus]

Also one additional note from me, if you are having some google IoT devices (as well others can do it) those specifically scan network they are in, they are constantly broadcasting and trying to identify what is on your network.

When I got OPN 1st time at my home I was bit shocked what crap IoT device can do, I knew its bad but after seeing such stuff it was like a networking nightmare.

Regards,
S.

[CJ]

@rkoftan
Its definitely a IoT device. I have seen this on my network as well. A lot of devices even if their DNS was set for my PiHole wanted to chat and preferred google. Additional to that some IoT devices tried to communicate with wierd destinations.

By hard coding DNS servers into their config, IoT devices still work when people have misconfigured networks.  One less issue for the manufacturer to support.

Most of the backends are in some cloud provider or another which leads to a bunch of random IPs being connected.  Since OPNsense lets you create ASIN aliases you could use that to lock down the device to those specific cloud providers.

[Seimus]

@rkoftan
Its definitely a IoT device. I have seen this on my network as well. A lot of devices even if their DNS was set for my PiHole wanted to chat and preferred google. Additional to that some IoT devices tried to communicate with wierd destinations.

By hard coding DNS servers into their config, IoT devices still work when people have misconfigured networks.  One less issue for the manufacturer to support.

Most of the backends are in some cloud provider or another which leads to a bunch of random IPs being connected.  Since OPNsense lets you create ASIN aliases you could use that to lock down the device to those specific cloud providers.

Indeed there is a certain logic why for example DNS is hardcoded on IoT device, but on the other hand it takes from you the possibility of control. The problem I have with this is that their hardcoded DNS will be always preferred...

I did find a solution for this.
If IoT device has a DHCP assigned DNS as in the DHCPOFFER, it will be used only in case of a fallback e.g. if those hardcoded DNS servers can not be reached it uses your DNS server. Basicaly what I did is to block communication with external DNS servers and allowed only queries to be made towards my self hosted DNS (I did this for every VLAN I have). Only my recurcive DNS server can talk outside. Effectively this will keep any device that wants to bypass your DNS to use your DNS.

Regards,
S.

[Patrick M. Hausen]

Another method is using a NAT port forward rule to redirect any DNS request to the server on OPNsense regardless of the real destination address.

Years ago at CeBit fair one of our established suppliers presented an - at the time - incredibly hot piece of WiFi hot spot gateway. It worked directly on layer 2 and no matter what the IP configuration of some misconfigured client (e.g. laptop) - that means static IP address, static gateway, static DNS, none of that matching the local setup ...

That box simply intercepted every packet on layer 2, analysed what the client system thought its gateway and DNS server were and then served the requests and routed and NATed with the proper reply source addresses.

Really clever ...

[meyergru]

Which works until chinese cloud device manifacturers start using DoH or DoT. Intercepting that traffic would render DNS for such devices invalid.

Many devices actually need to phone home in order to enable their functionality.

In order of descending preferability, I usually:

1. Try to use devices that do not phone home at all, preferably with open source firmware like Tasmota.
2. Try to find devices that do not phone home if so instructed (Unifi being an example).
3. Confine IoT and other devices I cannot fully control to an IoT network that has internet access, because I know that any of them actually pierces my firewall and thus cannot be trusted.

It is especially interesting to see which networks these devices contact. A while ago, I saw contacts to the Alibaba cloud from a friend's network. Upon investigation, we found that the devices in question were "upCams". It is a german manufacturer whose website says these are "security cameras" and suggests that they are developed by the company itself. They also say that the cases of their cameras are being used by other manufacturers as well so they might look like others.

Yeah, I am completely convinced that they do not use chinese manufacturer's devices that also provide a brandable cloud solution... ;-) To be fair, at least that part of the cloud was hosted in the EU, so it is not outright a GDPR violation.

[Seimus]

Another method is using a NAT port forward rule to redirect any DNS request to the server on OPNsense regardless of the real destination address.

Years ago at CeBit fair one of our established suppliers presented an - at the time - incredibly hot piece of WiFi hot spot gateway. It worked directly on layer 2 and no matter what the IP configuration of some misconfigured client (e.g. laptop) - that means static IP address, static gateway, static DNS, none of that matching the local setup ...

That box simply intercepted every packet on layer 2, analysed what the client system thought its gateway and DNS server were and then served the requests and routed and NATed with the proper reply source addresses.

Really clever ...

Interesting, just for funzies do you remember the name of that product and if its was even manufactured?

Which works until chinese cloud device manifacturers start using DoH or DoT. Intercepting that traffic would render DNS for such devices invalid.

Many devices actually need to phone home in order to enable their functionality.

In order of descending preferability, I usually:

1. Try to use devices that do not phone home at all, preferably with open source firmware like Tasmota.
2. Try to find devices that do not phone home if so instructed (Unifi being an example).
3. Confine IoT and other devices I cannot fully control to an IoT network that has internet access, because I know that any of them actually pierces my firewall and thus cannot be trusted.

It is especially interesting to see which networks these devices contact. A while ago, I saw contacts to the Alibaba cloud from a friend's network. Upon investigation, we found that the devices in question were "upCams". It is a german manufacturer whose website says these are "security cameras" and suggests that they are developed by the company itself. They also say that the cases of their cameras are being used by other manufacturers as well so they might look like others.

Yeah, I am completely convinced that they do not use chinese manufacturer's devices that also provide a brandable cloud solution... ;-) To be fair, at least that part of the cloud was hosted in the EU, so it is not outright a GDPR violation.

I totally agree with you on all points. I am actually doing similar stuff you describe,

• Control
• Limit
• Remove

For example I was pretty pissed with Google Assistant. On the start when I got, it was using your DNS, it was not spying it was not flooding. With time it started to use only Google DNS - so it was controlled. Then it started to spying on network level - so it was limited. Then it started to flood - so it was removed.

I have as well another funny story with Tesla vacuum smart cleaners and their Support and R&D, where I found they are spam flooding Chinese NTP server even thou product is sold in EU.

My strategy is if you can not control it, then remove it.

Regards,
S.

[CJ]

Indeed there is a certain logic why for example DNS is hardcoded on IoT device, but on the other hand it takes from you the possibility of control. The problem I have with this is that their hardcoded DNS will be always preferred...

I did find a solution for this.
If IoT device has a DHCP assigned DNS as in the DHCPOFFER, it will be used only in case of a fallback e.g. if those hardcoded DNS servers can not be reached it uses your DNS server. Basicaly what I did is to block communication with external DNS servers and allowed only queries to be made towards my self hosted DNS (I did this for every VLAN I have). Only my recurcive DNS server can talk outside. Effectively this will keep any device that wants to bypass your DNS to use your DNS.

I can't speak to whether it's configured to prefer one server over another, but like you, I block all DNS traffic that isn't destined for my own server.  Keep in mind that even if you block 53 and 853 that DoH will still bypass your setup.

Another method is using a NAT port forward rule to redirect any DNS request to the server on OPNsense regardless of the real destination address.

I'm not a big fan of that approach.  I'd rather outright reject anything destined to outside my network.  I provide a perfectly valid DNS server address via DHCP.  Silent redirection makes for fun troubleshooting until I remember it's there. :)

Years ago at CeBit fair one of our established suppliers presented an - at the time - incredibly hot piece of WiFi hot spot gateway. It worked directly on layer 2 and no matter what the IP configuration of some misconfigured client (e.g. laptop) - that means static IP address, static gateway, static DNS, none of that matching the local setup ...

That box simply intercepted every packet on layer 2, analysed what the client system thought its gateway and DNS server were and then served the requests and routed and NATed with the proper reply source addresses.

Really clever ...

Interesting.  I hope it at least provided some way for you to know about misconfigured equipment.

[Patrick M. Hausen]

Interesting.  I hope it at least provided some way for you to know about misconfigured equipment.

That product was intended for public WiFi hot spots. The point was not to need to care about any client configuration but just provide "Internet" to everybody who paid for e.g. a 1h voucher.

Unfortunately I do not remember the name of the product and that supplier in Hamburg has long gone out of business. One of our favourite partners to work with, extremely competent, technically, but seemingly made a bad business decision or two.