[SOLVED] VLAN isolation and router access questions

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello all,

I am new to Openwrt, and am having trouble trying to figure out a few things. Hopefully someone can point me in the right direction.

I am trying to create a fairly simple setup. I have a home scenario with three hard-wired computers and one computer on wireless. My primary goal is to get as close as possible to complete isolation for each computer. I don't want any computer to see or be able to get to any other computer or to the router. I have a very slow (about 6 Mbps) Internet, so my goal with Openwrt doesn't center around improving the wireless. I don't need to do anything fancy with that. I only want Internet access for each computer and that's all. Each VLAN has one virtual interface that has a firewall zone forwardings rule that is only interface x --> wan and that's it.

I started by building upon the default VLAN configuration, adding three more VLANs (ignore the additional extra VLAN 40, I thought I needed one for the wireless, so I guess I will just delete that one out. I unbridged the wireless and it sits by itself in the interfaces page.).

VLAN%20layout
VLAN layout.png954×434 18.4 KB

My approach is to have each physical port on the router be assigned to its own VLAN. Three ports would be for the three computers, and the remaining port would be the only access for the Luci interface (which I assumed will be the lan port 1, the default lan). I have an additional 'extra' computer dedicated just for this access, and it will only be plugged in when I want to access the router to make changes, and only when the other computers are unplugged and the modem is turned off i.e. no Internet access. I have been told this is overkill, but I would like to do it this way.

Let me say that I am doing most of this via Luci, as I am not too skilled with CLI. I can SSH into the router and use a text editor to make changes when I need to if it's something that can't be done via Luci (like change the access port number from 443, for example). So far this has worked well.

Here's what I am trying to figure out. From any VLAN/router port/computer I can still access the router via the Luci interface. My goal is to only be able to access the router by let's say port 1 (no wireless access either). I noticed, by accident, if I set the the input to reject for that interface I could no longer access the Luci interface. I only did this because in reading one post the person said there is no reason in a situation like this to accept input. I found that I can access the Internet fine set to reject input. The only reason I initially had it set to accept is because the default lan zone was set that way. So, is this the correct way to block router access from the other ports/wireless? Make sure input is set to reject? Or is there a better way?

The other thing I need to be sure of is that computers on different VLANs can't communicate with each other. I thought that the very nature of a VLAN on a different subnet would accomplish this. Right now I am not able to ping any computer from any other computer when set up as described. But I read a post where the person described quite an elaborate set of firewall rules to block access from one VLAN to another. Is this necessary (or just a good second layer to do the same thing)? Or was that done because the person wanted to accept input and this is the only way to block cross VLAN traffic when accepting input? That doesn't sound right because I wasn't able to ping any other computers even with input set to accept... What's the best way to assure isolation?

Finally, I was changing my Luci access port as mentioned above, based on instructions from this page:

https://openwrt.org/docs/guide-user/base-system/uci

Scroll down to 'Securing uHTTPd' and it says:

"By default, uHTTPd is bind to 0.0.0.0 which also includes the WAN port of your router. To bind uHTTPd to the LAN port only you have to change the listen_http and listen_https options to your LAN IP address. ...edit /etc/config/uhttpd and bind listen_http to specific 192.168.1.1 IP instead of 0.0.0.0 and comment out IPv6 bindings"


config uhttpd main
        # HTTP listen addresses, multiple allowed
        list listen_http        192.168.1.1:80
#       list listen_http        [::]:80
 
        # HTTPS listen addresses, multiple allowed
        list listen_https       192.168.1.1:443
#       list listen_https       [::]:443

I thought that this would then only allow access from the lan port, but it didn't change anything. I could still access the Luci interface from any port, and I didn't notice any other differences. Can someone explain in simple terms what this actually does, then, and if this in any way ties into what I am trying to do?

I am sorry for so many questions. I have spent more hours than I can count trying to figure this out on my own. I am here because I just can't get anywhere on this. I've read all the documentation and forum posts I could find. Thanks.

2

The router will, unless prevented, route across the subnets. By default, it knows that, say 192.168.1.0/24 is out VLAN 10, 192.168.2.0/24 is out VLAN 20, ... , and that it has its own interfaces as well. So while the VLANs are on different subnets, the router gleefully routes one to another. I thinks that's its job (which it is).

You'll need firewall rules around forwarding packets from one VLAN to another, as well as around accepting packets destined for IPs on the "other" interfaces of the router (including, perhaps, where you have LuCI running).

Edit: This is a general issue with routers (and Layer 3 switches), not something that is OpenWrt specific.

1 Like
3

What firewall zone is each vlan in? What is the firewall policy for this zone, show the firewall page screenshot perhaps.

1 Like
4

Thanks for the fast replies.

Here is my firewall zone layout.

Firewall%20layout
Firewall layout.png958×406 34.7 KB

5

Ok, by default you are putting VLAN_X into a firewall zone that has no forwarding ability (the menus in the "forward" column), and then opening up forwarding only to the WAN (the VLAN_X => wan icons). This is exactly what you want, and is why the individual vlans can't talk to anywhere except WAN. You are also putting input -> reject on those vlans, and that's why they can't talk to the router itself. You may need special traffic rules to allow anyone to access DNS on the router, unless you require those VLANs to use WAN based DNS (ie. 1.1.1.1 or 8.8.8.8 etc)

1 Like
6

Thanks dlakelan. I was hoping what I had set up would be close to workable.

The DNS thing is rather curious. I found two rules for DNS and DHCP here (towards the end):

https://openwrt.org/docs/guide-user/network/wifi/guestwifi/guest-wlan-webinterface

I created similar rules for one of the VLAN_X. I then tested to see what would happen if I deleted the rules and I was still able to get out to the Internet. I made sure I flushed my DNS cache (and fully cleared my browser) before trying this. So, it seems somehow it is getting out for DNS. I do notice on the Status - Overview under Network IPv4 Upstream where it shows my ISP details it also lists their DNS servers there. Is it fetching from there via the wan and not from the router, so it gets through? Hence if I set the DNS on the router then I'd need the rule? Sorry I am so lacking in knowledge in this area...

Related to this is that things also seemed to keep working once I removed the DHCP rule, too. I haven't sat through a DHCP renewal attempt, which is where I suspect it would then fail without that rule, but it has no problem assigning an address to a new computer plugged in to a port with that rule removed (or using another VLAN that never had the rule at all). I'm trying to understand how all this works and not just blindly put in rules that I don't understand...

Any thoughts on any of this would be greatly appreciated.

7

Also, can you tell me (or should I start a new topic to ask this) what does the bind to my lan IP address do? From what I mentioned in my original post it seems like there could be potential wan access if it stays with the default bind to 0.0.0.0, but with the wan set to reject, is that possible? I couldn't find any documentation outside what I posted above, and nothing via any Internet searches that seemed to have anything to do with this.

8

Typically that tells the service "offer yourself on any and all IP addresses". For most users, that's a "safe, functional" option. The standard OpenWrt firewall rules prevent access to LuCI from the WAN.

If I run LuCI, I typically will set the bind address to the specific IP of my management VLAN. If you don't have a management VLAN, you could set it to the IP address of your LAN.

1 Like
9

Thanks for the fast reply Jeff. That's helpful. I had planned to use the default lan for management since I wasn't going to use it for anything else. Would you suggest I just use one of the other VLANs instead? I am still unclear on if the default VLAN with ID 1 has any 'special properties' being the 'default lan'.

10

Personally, I avoid the "default" VLANs of 1 and 2 as some switches consider them "special". As far as I know, there's nothing special about them from an OpenWrt perspective, just long-standing convention of how a "new" install has it's /etc/config/network created.

With "dumb APs", I typically use "the blue port" ("WAN", "Internet", ...) for management, as it's visually different than the ones for LAN.

1 Like
11

So, would you redo or relabel VLAN1 and VLAN2? Create two new VLANs and set them up like 1 and 2 and then turn off everything on 1 and 2? Or does my line of questioning show I have no idea about what I am asking?

12

I wouldn't unless I had a specific known reason to. Jeff's reason is that he uses things like Cisco switches which might by default do all their management on VLAN1 etc. If you don't have that kind of scenario, you probably can leave VLAN1 and VLAN2 alone.

2 Likes
13

Correct, if your computer sees DNS as proper internet addresses then it will send DNS requests to those addresses and those requests are allowed through.

There are reasons to do all your DNS off the router, like for example you can blacklist certain domains, or you can do caching to reduce the number of DNS requests needed on the WAN per unit time... but the reasons are not 100% compelling, it could be ok to let your clients use WAN based public DNS as well.

1 Like
14

Thanks dlakelan, that was helpful.

I was hoping to just leave the VLANs as they are.

As for the DNS, I actually use DNSCrypt locally on the machines (disabled for now as I test all this), but I wanted to figure out the OpenWrt implementation before I started that back up. Thanks to all this help I think I am starting to see how it all works.

1 Like
15

Back to the cross talk issue, I have noticed that although I can't ping computers between the VLANs at all, from any computer I can ping any interface. For example, from a computer on VLAN_10, with interface eth0.10 and IP address say 192.168.10.240, I can ping 192.168.20.1 or 192.168.30.1. My reasoning for all this separation is that one computer is for kids who may wind up on a malware infested site (despite all you teach them about Internet security...), and two computers are for different work related things. I want to reduce the chances of one infected computer compromising the other, or the router. So I wonder if there is some risk that malware that infects one computer, and can still ping and get a response from an interface IP address, will that alert them to a place to try to get further in? Should I look to write firewall rules to stop that?

And is ping a good test to see what can be found/accessed, or not? Is there a better way to test this? I can do basic stuff with Wireshark, but have no idea what I would need to look for, if it is even useful here.

16

A typical Linux-based firewall distinguishes between forwarding packets and accepting packets (destined for its own interface IPs). As long as you don't block the typically critical ones, like DHCP, DNS, IPv6 related to neighbor discovery and routing, NTP, you can also block your router from accepting packets to its own interfaces while still allowing them to be forwarded.

For one reference as to "how it all works" you could try

From that reference, a critical part is

  • Incoming packets destined for the local system : PREROUTING -> INPUT
  • Incoming packets destined to another host : PREROUTING -> FORWARD -> POSTROUTING
  • Locally generated packets : OUTPUT -> POSTROUTING

INPUT and FORWARD are the ones commonly used for "custom" tuning of the OpenWrt firewall.

1 Like
17

Thanks for that reference. I've been reading over there since you posted that. I follow some of it, but I may have reached the limits of my ability. Too bad I spent all these years on Windows instead of Linux...

Is this something you think good security practices would call for? Is it something very many users are doing? Or do you feel it's not worth the effort? I'm trying to understand if I should even be pursuing this.

18

You can chase packets to the end of the earth, and still have them leaking past you. It's a never ending battle unless you make some reasonable decisions about "good enough". Even with "valid" packets, there are nefarious ways that they can carry a backchannel.

Meh, in my opinion, once you're significantly more difficult to attack that other targets of comparable value, you're done. It's like safes. There's no "impenetrable" safe, they're rated in terms of minutes or hours of time before a skilled team can break into them.

Essential, in my opinion:

  • Use strong passwords and rotate them
  • Don't run any services on your firewall or router that aren't essential; put your file server or what have you on other hardware
  • Don't enable UPnP or anything of its ilk
  • If you need/want LuCI run it only over HTTP-S and only for your "trusted", wired network
  • If you have any Windows boxes, make sure you have current "virus protection" and it's enabled and regularly updated
  • Read your firewall rules and, if you don't understand them, ask

Challenging with OpenWrt, but important for me:

  • Add a user login other than root, with sudo
  • Disable root login
  • Use OpenSSH instead of dropbear (some may argue this one)

Reasonable, in my opinion (I'm probably more security-focused than many):

  • Isolate your IoT devices on their own VLANs by brand and, when possible from outside connectivity
  • Only "talk" to your IoT devices, if possible, through an application proxy (for example the TP-Link power switches I use have open-source Python to control them, and I make MQTT calls to a server that then relays to the devices)
  • Put your "critical" devices on a management VLAN
  • Separate your "guest" network from your important computers with a VLAN
  • If you can, separate your "personal wireless" network as well (assume that every wireless client is hostile)
  • Isolate anything that provides services to the outside world on its own VLAN; use containers, jails, or the like to isolate them from each other and from the host they run on
  • Don't run anything but "professional" servers if you're offering services to the outside world (for example, nginx, yes, uhttpd, no)
  • If you can, run an intermediate proxy (for example, an instance of nginx only running as a reverse proxy for your internal webserver)

Getting over the top, even for me (though some of these I do implement):

  • Double firewalls with two different technologies
  • Intrusion detection systems (IDS), multiple, different IDS
  • "Deep packet inspection" in firewalls
  • Real-time log analysis tools and monitoring
  • Only allow ssh-key access for privileged accounts or to sensitive devices
  • Require two-factor authentication
  • Use 802.1X port-based authentication
  • Use 802.1X authentication on wireless networks for clients that support it (consumer IoT devices generally don't)
  • Anything that an alert "rings my pager" so I can immediately respond (well, except for power outages)

I've certainly missed some, but that should at least be a good idea of one person's opinion.

Note that I don't believe that, for example, "ShieldsUp!" and his suggestions are worth a damn, nor is blocking ping worth the problems when diagnosing network problems, or that putting a service on a non-standard port does anything more than reduce log clutter if you've got strong passwords.

3 Likes
19

Wow, Jeff, that's quite a reply. Very, very useful. I did have two questions. I am new to having a Linux box, about 3-4 months, but I dabbled over the years. I never use the root account, only a user account. I was advised to not install sudo, but use su instead, which has worked great for me. The reasoning was it was a less vulnerable approach. Can one use a similar approach here, or is sudo required? Also, it seems to me that if I use Luci don't I have to log in as root to make changes? I'm a bit confused because one piece of advice was to change the login name from the default root, but in Linux root has a very specific meaning. I am wondering how to operate in Luci once I set up a non-root account. I suspect you will say Luci is just for beginners so get away from it as soon as you can. Any clarity here would be appreciated because this was on my list of questions that I couldn't find answers to.

Also, I do treat any wireless client as hostile. The 'kids' connection is the wireless, and one of my primary motivations to set all this up. There is only the one wireless client (one computer using it), and there will never be any guest WiFi. Is there anything more I can do outside of what we have been discussing in this thread as far as isolating this wireless client? As far as I can tell I don't attach this to any VLAN (like my 'extra' VLAN_40) because I do not want to tie it to any router port or other device in any way. So as long as all other clients are in VLANs with proper firewall rules (as discussed above) it is 'isolated'? (I also checked the 'Isolate Clients' checkbox hoping that would help if anyone 'hacked' the WiFi.)

20

I prefer sudo as at least it gets logged and on my boxes, where I can, there is no root login. Not that once someone has root access they can't change the logs on a local Linux machine, but at least you have a chance of seeing failed attempts. I'm sure there's "religion" around su vs. sudo, but it's not one that has convinced me to change my preference. sudo also has saved me a few times from my own stupidity because of its command-by-command style, as long as you're not running sudo sh and blindly typing away.

On LuCI login, it used to be the case that root credentials were used. This may have changed since I last looked into it, but I almost never install LuCI on my OpenWrt boxes, so I haven't followed it closely. I have noticed that, at least on master, LuCI on nginx with OpenSSL is a pre-packaged option. Looking deeper into those if you're using LuCI might reveal more than I have kept up with.

Yes, UID 0 and GID 0 have reserved meaning in Unix-like systems. There's nothing that says the name of the user or users associated with that account needs to be root. FreeBSD, for example, defines one user with those IDs to be root as the "safe, predictably robust" user that (should) always have /bin/csh and a clean environment, and toor as one that can, if one wants, have a different shell, home directory, environment, ...

1 Like