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"
...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.
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.
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.