How to provide internet access without LAN access?

CodeOptimist · 2021-10-20T03:46:24.319Z

My GL-AR300M-Lite is connected to my primary router to provide a 2.4GHz AP for my IoT devices. I want them to have internet (cloud) access only, no LAN access.

Created a guest network, connected them. Connected to the guest network myself, was able to ping devices on the primary subnet perfectly fine - fail.

So I tried turning on client isolation though AFAIK that’s just between the guest clients, either way, still able to ping primary subnet devices - fail.

Saw this guide: [OpenWrt Wiki] Guest Wi-Fi extras “Allow guest clients to access the internet but restrict upstream access.” well that sounds about right. Connected via PuTTY and executed the commands, restarted. Still able to ping primary subnet devices - fail.

"Well maybe because I set the guest wifi up with the GUI, and then used these CLI commands, the names didn’t match so it didn’t configure the right thing. Reverted to default settings, followed [OpenWrt Wiki] Guest Wi-Fi basics, then followed https://openwrt.org/docs/guide-user/network/wifi/guestwifi/extras#restricting_upstream_accesswireless_ap. Can still ping primary subnet devices - fail.

Okay, so I need to tag the guest wifi with a different VLAN to properly isolate them right? That’s been the solution all along. Find this: https://openwrt.org/docs/guide-user/network/vlan/switch_configuration. So I edit /etc/config/network via WinSCP, add option vlan '3' to config interface 'guest', restart. Try to ping devices on primary subnet, still get a response! fail

Can someone please tell me how the hell to configure my GL-AR300M-Lite to provide internet access only? Do I need to block everything but the internet gateway IP in firewall rules or something maybe? Why is this so hard?

Thanks,
Chris.

P.S. if you’re wondering why I want this, it’s due to this 5-year-still-broken LIFX LED hell: https://community.lifx.com/t/its-not-you-its-the-app/1935

alzhao · 2021-10-20T05:06:58.385Z

I am not sure how did you set up guest wifi.

I have a AR750s at hand and I just enabled guest wifi from the GUI.

image2134×814 84.6 KB

Clients connected to the guest wifi is in a different subnet and it is isolated from the private network.

I checked ping and verified and it is a pass.

image1082×458 63.4 KB

CodeOptimist · 2021-10-20T05:19:37.660Z

Thanks for the reply.

Yup it’s setup like your screenshot.

In the 192.168.9.X subnet and yet still able to ping devices in the 192.168.10.X subnet. Mask is 255.255.255.0. I actually wondered if I had a separate network adapter enabled allowing me to ping the .10.X devices, but not so.

But I will now re-verify this since your reply.

Yup, in the guest .9.X but able to ping .10.X devices just fine:

I really hope I am doing something incredibly stupid because it’s been very frustrating.

No other adapters connected https://i.imgur.com/6T9ZH41.png (I randomly generated the guest wifi SSID is why it’s weird).

The gateway is 192.168.10.1, so there is obviously a route to that subnet, but I want access only to the gateway, not other devices in the gateway’s subnet.

alzhao · 2021-10-20T15:16:22.319Z

I am not sure what else changed. But can you just keep everything unchanged, including the subnet, i.e. the private subnet 192.168.8.1 and guest subnet 192.168.9.1, and verify?

Maybe just do a firmware reset and try again?

CodeOptimist · 2021-10-20T18:01:06.080Z

Every new thing I try is after a reverted/reset firmware, my only other changes ever are the guest SSID and WPA2 security key, and router login password.

I have 0 devices on 192.168.8.X, my normal network is a primary router at 192.168.10.X, the WAN side of the GL-iNet router.
I am only using the guest wifi of the GL-iNet router - I’m not using the regular wifi except to configure it. The router is connected via ethernet to my primary router.

I can perform that test for you though, I expect it to work, 192.168.8.X and 192.168.9.X are probably separated, that just isn’t my problem. But I will check!

That does work fine, but isn’t my issue.

image642×512 17.9 KB

A friend has been helping me. Basically from the perspective of the GL-AR300M-Lite, what I want is the equivalent of rejecting an “internet” address of 192.168.10.2-254 since this is all “WAN” side of the travel router.

The reasonable thing to do is configure the primary router to consider the travel router a guest, which I’m working on now. Thanks for your replies alzhao.

CodeOptimist · 2021-10-21T03:59:52.555Z

Thanks anyway, but 12+ hours and 3 routers later and I’ve completely given up.
Has very little/nothing to do with GL.iNet devices as I ran into much of the same problems with an extra FreshTomato router. The way my networks are bridged, seems nigh-impossible to restrict access to devices on the subnet of the most upstream router from the first router or an intermediate router. Or at least, I can’t figure it out.

Consider this closed.
May want to rename title, “How to allow access to only internet (not devices) in WAN subnet?” or something, I seem unable to.

alzhao · 2021-10-21T09:48:47.095Z

CodeOptimist:

May want to rename title, “How to allow access to only internet (not devices) in WAN subnet?” or something, I seem unable to.

I believe there are solutions.

Using firewall

You can drop data if the source IP is from 192.168.9.x and to 192.168.10.x, but not 192.168.10.1
You need to put the iptables rules in the router’s firewall. (sorry to ask you to write the iptable rules by yourself)

image2080×920 149 KB

In Luci UI you can try the following (not verified)
Pls note you may need more detailed rules. You cannot drop all data to 192.168.10.1 because you will have no DNS

image1816×1228 133 KB

Using VPN

Another solution is to set up vpn on the mini router. Once vpn is connected it shield your main router totally.

CodeOptimist · 2021-10-21T21:57:59.741Z

I haven’t tried adding adding custom iptables rules - that is a good idea. I will try it when I get some time. Thank you.

Just FYI I did try a Traffic Rule through the Luci UI. I couldn’t make it work. I tried to set it as broadly and simply as possible with the following three:

Source zone: any zone
Destination zone: any zone
Destination address: 192.168.10.146
Action: reject
(labeled as a "forward")

Source zone: this device
Destination zone: any zone
Destination address: 192.168.10.146
Action: reject
(labeled as an "output")

Source zone: any zone
Destination zone: this device
Destination address: 192.168.10.146
Action: reject
(labeled as an "input")

None of them made a difference, I was able to ping 192.168.10.146 perfectly fine from both guest wifi and regular wifi (I set the rules broadly for best chance of a result).

I also tried rearranging the rules in case an “allow” was overriding a “deny”, or something, but it made no difference.

alzhao · 2021-10-22T05:49:10.316Z

Stupid question:

Did you save and applied, or rebooted?

Maybe just set up a vpn on the router.

CodeOptimist · 2021-10-23T03:24:14.082Z

Good point, perhaps the firewall wasn’t restarted?

Anyway I got this to “work”. iptables on the router with the guest wifi didn’t help (at this point it’s a FreshTomato router, not a GL.iNet router, sorry I don’t have info on that), presumably because it’s bridged to my primary router. iptables on my primary router (the 192.168.10.X subnet) did take effect, as noted by how many packets the rule matched in iptables log, and my Google Home Hub being unable to find the LIFX LEDs with the rules enabled.

Unfortunately it was all useless. I blocked both incoming and outgoing packets to my LIFX LEDs and while it successfully disabled their cloud access, it did not disable LAN communication (so the exact opposite of what I wanted).

I can only guess this is because the cellphone app sends UDP packets that aren’t dropped by the router firewall??? I thought those could be routed too, but rejecting everything only blocked cloud access.

Thanks for the help alzhao, I’m going to take this up with LIFX support I guess, even though I’ve had to deal with this for 3+ years, apparently not everyone is so afflicted by incredibly unresponsive lights (across multiple router swaps).

alzhao · 2021-10-23T04:38:33.439Z

CodeOptimist:

apparently not everyone is so afflicted by incredibly unresponsive lights (across multiple router swaps).

OK. No problem.

But can you let me know why you do this? Usually people do this because they don’t want the IoT device connects to their private network because of security concerns.

LiFX connect direct to their cloud, right?

CodeOptimist · 2021-10-23T04:51:23.866Z

alzhao:

But can you let me know why you do this? Usually people do this because they don’t want the IoT device connects to their private network because of security concerns.

Yeah. This is not my reason. I just want the damn lights to work. They only respond correctly about 60% of the time.

alzhao:

LiFX connect direct to their cloud, right?

LIFX uses both LAN and cloud. The smartphone app prefers to work over wifi, and it’s less reliable over wifi, possibly because of the choice of UDP??? But it’s really bad, UDP shouldn’t be this bad. People on the LIFX forums say when they write Python programs, it works 100%, thus the app is explicitly coded badly.

Turning off wifi every time I open the LIFX app is extremely annoying (and slow).

Honestly the lights glitch even with wifi disabled on my phone, and through voice commands with my Google Home Hub… both cloud, so… meh.