I want to block a particular IoT device from the internet -- so I used luci to create two "firewall - traffic" rules; it created this stuff pasted below, and then i did a save/apply
# /etc/config/firewall
uci add firewall rule # =cfg1292bd
uci set firewall.@rule[-1].src='wan'
uci set firewall.@rule[-1].name='block gadget inbound'
uci set firewall.@rule[-1].dest='lan'
uci add_list firewall.@rule[-1].dest_ip='10.1.1.50'
uci set firewall.@rule[-1].target='REJECT'
uci add_list firewall.@rule[-1].proto='all'
uci add firewall rule # =cfg1392bd
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].name='block gadget outbound'
uci add_list firewall.@rule[-1].src_ip='10.1.1.50'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].target='REJECT'
However, it appears both looking at tcpdump , as well as it's app thru "the cloud" continues to work. ??
Obviously i'm missing a step!
hmmm. i'm not sure exactly the lingo; but i only have one Lan, it's 10.1.1.0/24
i don't have anything extra going on.
If it helps, once upon a time i wanted to force a different gadget (a google hub) to use my pi-hole as its DNS (as apparently the google gadget uses their own dns regardless of what dhcp tells it), and I found this incantation on the internet somewhere, and it seemed to work for that application; this was added as a "firewall - Custom rule"
What specific evidence does tcpdump show of successful outbound connectivity despite your firewall rules? Can you then use that evidence to tailor your existing rules or add new ones?
...hmm, let me defer the tcpdump for the moment.
I can tell you for sure that if I take the phone with the app, disconnect from my wifi, and connect it thru mobile data (i.e. not connected to my LAN), everything continues to work; the app still controls the gadget.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I have no doubt that's what you're seeing. So the requirement is to identify why traffic is still possible despite firewall rules which ostensibly ought to prevent it.
that does not necessary mean you have ingress traffic: your gadget can connect to cloud hub, i.e. initiate an egress traffic and receive commands from the cloud hub which is controlled by your phone app.
so let's see the requested files first please before you, we make assumptions, let's stick to facts.
correct, they were just cut/pasted for reference. (i.e. by pressing save/apply, the firewall gets restarted, I believe).
I will get with files that were reqested below in a little bit...
An hypothesis: your IoT may be connecting to a cloud server (LAN -> WAN), and the app from your phone is connecting to the cloud server which then uses the existing connection opened by your device.
If this is the case, then you should trying blocking your device from having any access to the internet (i.e. outbound connection, src='lan', dest='wan', target='REJECT').
Another possibility is that the device keeps a persistent connection that restarting the firewall does not “break”. You can flush the conntrack table for this IP with:
I may have been leading a wild goose chase.
I hadn't mentioned (because i didn't think it was important) that I have the gadget (it's a midea air conditioner) integrated into Home Assistant,
that allows me to control it thru my lan. (HA runs on a rasp Pi on my lan).
It works in "parallel" with the app; in other words i can change a setting on the app and the change is quickly reflected in HA, and vice versa.
Once I stopped running HA, the app "broke" (says unit is offline) -- presumably due to the firewall rules.
When i remove the rules everything goes back to working as expected.
I can't fathom the connection, but HA has something to do with it.
in any event, i believe the firewall rules were obviously in fact blocking it all the long.
Anyway, your firewall rule blocking WAN to LAN for this specific device is not needed nor effective. By default firewall will block all incoming connections from WAN to LAN. Even if it did not block, since you are using private IPv4 addresses in your LAN (not reachable from the internet), in order for a device on the internet to have direct access to a device in your LAN would require port forward.
So in fact your Home Assistant was opening a connection from LAN to WAN (the 'cloud' hypothesis I mentioned before) allowing it to control your IoT from the Internet.
Notice that many IoT devices, when you configure the cloud account directly in a device, it will work the same way (for example, I have some TP-Link TAPO cameras that connect directly to the TP-Link cloud service and allow me to see and manager the cameras from the phone app anywhere, since the app is accessing the cameras via TP-Link cloud).
Though I'm continuing to not understand the bigger picture; and I'm not able to reproduce some of the things I said above, e.g. the business about how stopping/starting HA appeared to prove something about the firewall rules. So don't rely on that.
Regardless, I just double-checked, and yes, i can disconnect my house's internet (by literally pulling the plug), and I can continue to control the gadget using HA solely thru my LAN.
This was, by the way, as-advertized by that particular integration "Control your Midea M-Smart appliances via local area network." (my emphasis. You have to use their cloud to intially set up the gadget, but that's all).
So I think i finally understand what's going on...
It's as @dave14305 said about persistent connection, but I neglected to check out at the time. The firewall rule was doing what I expected, but the app kept working only because the connection was already set up. Flushing conntrack did the trick (i just flushed the whole thing, i guess):
echo f > /proc/net/nf_conntrack
I imagine if i would have thought to power-cycle the gadget, that would have had the same effect.
As @dsouza mentioned, the one rule I started out with that blocks from wan to lan is redundant/unnecessary.
