#Blocks wifi devices on interface eth1 and eth2 from accessing router GUI
ebtables -D INPUT -i eth1 -p ip4 --ip-protocol tcp --ip-destination $(nvram get lan_ipaddr) --ip-destination-port 80 -j DROP
ebtables -I INPUT -i eth1 -p ip4 --ip-protocol tcp --ip-destination $(nvram get lan_ipaddr) --ip-destination-port 80 -j DROP
ebtables -D INPUT -i eth2 -p ip4 --ip-protocol tcp --ip-destination $(nvram get lan_ipaddr) --ip-destination-port 80 -j DROP
ebtables -I INPUT -i eth2 -p ip4 --ip-protocol tcp --ip-destination $(nvram get lan_ipaddr) --ip-destination-port 80 -j DROP
Just curious.
I realize this use of ebtables works because it's blocking at the ethernet level, where it "peeks" into the IP layer to see what the destination IP is for blocking purposes.
However, I don't really see the point of it. Anyone who would be a threat via wireless (at least in my thinking) wouldn't/shouldn't be on the primary wireless network interfaces anyway! I'd have them on their own wireless guest/IOT ethernet/IP network (e.g., 192.168.2.x), where I can simply block them at the IP level.
Also, this blocking technique is only effective on that particular wireless router, whereas blocking at the IP level will be effective everywhere, even if you later introduce OEM APs and repeaters.
It seems mighty inconvenient to completely rule out access to the router's GUI via wireless when using the primary network, esp. when the number of wired devices seems to be dwindling every day. I know in some cases ppl have NO wired devices at all.
My gut tells me that anyone using this technique, while effective, really has an underlying network misconfiguration. You shouldn't have "threats" on your primary network in the first place. That's why it's considered private, and implicitly trusted. If that's not the case, those devices don't belong on the private network, whether wired or wireless. IOW, the distinction shouldn't be wired vs. wireless access, but private vs. public access.
Perhaps I missing something, but when I saw this, it just struck me as odd.
JMTC
The same points were raised in the 3rd link I posted and the subsequent comments from RMerlin.Perhaps I missing something, but when I saw this, it just struck me as odd.
I'm not 100% clear on what you're looking for but doesn't this get you what you want if you establish a fixed IP map for the devices you want to allow into the GUI?Hi all,
Does anyone have ready to use iptables rules for blocking wifi interface from accessing router GUI or ports 80, 443, 22? Or if it's easier to allow access to just LAN interface clients to router GUI, and blocking everything else?
Thank you.
I'm not 100% clear on what you're looking for but doesn't this get you what you want if you establish a fixed IP map for the devices you want to allow into the GUI?
View attachment 17945
Ya, I got that point but it seemed he was more interested in restricting who got access to the GUI more than wired vs wireless. That was more a method than a goal is what I read into it. But ask my wife, I've been wrong a dozen times already today!The OP wants to make a distinction between wired vs. wireless clients, which isn't possible at the IP level since all the wired and wireless devices are bridged (br0). That's why it was suggested to use ebtables, which works at the ethernet layer and can distinguish between wired and wireless devices, then "peek" into the IP layer to see the destination IP.
Ya, I got that point but it seemed he was more interested in restricting who got access to the GUI more than wired vs wireless. That was more a method than a goal is what I read into it. But ask my wife, I've been wrong a dozen times already today!
PS - I believe on that same page I took the screen scrap from, the SSH access has a "LAN Only" option. Not sure if that means wired only. I typically see LAN and/or WLAN to differentiate. IF that's wired only it would seem detection in the software could be easily done. I know, I know, that's a feature request but just thinking out loud here.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!