Complex home network architecture feasibility (incl. WAN fail-over and VLANs)

Installing and Using OpenWrt Network and Wireless Configuration
1

[Apologies in advance for the long post!]

Hi guys.

I'm thinking about redesigning my network architecture.

My goal would be the following high-level design, and I'd appreciate to hear your view about the feasibility to implement this with standard OpenWrt gear and "el cheapo" switches:

  • Dual WAN setup with automatic fail-over: I have one fibre-optical internet line (400 MBit/s down, 200 MBit/s up), terminated in an optical network terminator ("ONT", media bridge fiber-to-Ethernet that "speaks" DHCP) and a DSL super-vectoring line (250 MBit/s down, 40 MBit/s up), terminated in a Fritz!Box running FritzOS
  • Powerful Linksys WRT1200AC router which is my main router/internet gateway
  • Multiple el-cheapo routers flashed to OpenWrt, acting just as plain WiFi access points
  • Multiple el-cheapo switches to allow for a more complex physical setup across some rooms/floors

For the internet connectivity, I plan the following (and I believe it's possible, because I had a similar setup running some years ago already, using LTE as the fail-over WAN connection):

  • Fibre to be the "main" internet connection; ONT connected to Linksys' WAN ethernet port, with the router obtaining an IP address directly from the ONT with DHCP
  • DSL line to be the fail-over; one of the Linksys' Ethernet ports would be defined as a secondary WAN port, it would be connected to one of the Fritz!Box's LAN ports, from where packets would be masqueraded and sent thru the Fritzbox's WAN port (DSL line); so in this case the Linksys would not be the gateway, it would just be a router routing packets to a different gateway (the Fritz!Box)

Now the tricky part. I know in principle it should also be possible, but I'm not sure which challenges I might face:

  • All access points should have two WiFis (SSIDs actually): one "trusted" WiFi, and one "guest" WiFi. Traffic coming in via either of these wireless interfaces must be completely separated from the either WiFi.

I know this can be done with VLANs, and I also know that OpenWrt can do this in principle. What I'm not sure about: Would I have to tag each of these VLANs, or could I have one "untagged" VLAN ("trusted") and one "tagged" VLAN ("guest") configured?

Background of my question about mixing "tagged" and "untagged" traffic on one port/cable is my idea to have all my "trusted" traffic untagged (because somehow I feel that's simpler and "more resilient" against misconfigurations, also some devices may not even be able to "tag" Ethernet frames, especially cheaper devices like printers).

(Can untagged traffic remain untagged, or would the "untagged" traffic have to be "auto-tagged" to a default VLAN?)

I'm using several switches inside my house. Will every el-cheapo switch be able to handle tagged Ethernet frames, or does it need a "smart" (managed) switch to be able to do so? Considering that the VLAN tag is included in the middle of the Ethernet frame, with the Dest/Src MAC address at the beginning, I believe using el-cheapo switches could work, because the VLAN tag (and even the fact that the frame is a "tagged" frame) would be simply "invisible" to them?

  • Traffic from all "trusted" WiFis and all (by definition "trusted!") ethernet ports should land in the same IP network (regardless of which physical AP they originate from), and traffic from all "guest" WiFis should land in a different (but for all guests the same) IP network. This way I could prohibit "guest" traffic to be routed by the Linksys to the "trusted" network (where for example my NAS devices reside), but allow it to just be routed (and masqueraded) to the WAN port.

Ok, I hope you're still with me at this point. I'm eager to hear your comments about my intended design, and whether it's feasible.

Many thanks in advance.

Kr,

Ralf

2

get yourself

  • a pc running virtualbox
  • a laptop (optional)
  • an ap (optional)
  • a managed switch

whip up different elements of the design in a lab topology and verify the key elements in isolation...

attempting this on your production network is not advised...

depends... for a beginner... tag everything

later down the track, once you are confident in your skills... then attempt to allow 'untagged' over various ports in the topology... doing this is traditionally a 'fallback' design element... and not something you mix and match across the network...

3

The behaviour of unmanged switches in the presence of VLANs is undefined, in the worst sense of the word. While some might pass the VLANs through unchanged, might block them, strip them, crash or expose hard to debug, more subtile issues. The only safe advice would be to exclusively use (smart-)managed switches for connections seeing (any-) tagged traffic, you want them for security/ reliability anyways (don't trust your endpoint devices not to sneak into VLANs they have no business looking at, strip the unnecessary ones at the switch ports).

1 Like
4

Hey,

thank you very much for your response.

Of course I would try to test everything in a lab environment. That goes without saying. I cannot afford to break my home network. I'm working from home since the begin of the pandemic, and also my family needs the internet badly, especially my daughter... :wink:

Just to understand: Why are you suggesting to use VirtualBox? Do you suggest creating multiple virtual "PCs" on VBox to simulate multiple LAN clients? Using "bridge mode" for the network interfaces, I suppose? I would be able to connect multiple laptops into my "lab environment," I guess that would be preferable?

To understand your comment about tagged and untagged frames: You mean devices connected to the router's ethernet ports should explicitly tag ethernet frames on the client device? That is something I really would like to avoid. I consider it "risky." What if this setting somehow gets lost (during a driver update or OS update), and I'm not at home? My wife would be unable to set this up... It might also be hard to debug... Can you understand this fear, or is it somehow unfounded?

Thanks again for your comments.

Kind regards,

Ralf

5

Hi there.

Thanks also to you for your comments.

I appreciate your guidance about unmanaged switches very much, and it is fully understood. :slight_smile:

Re. your security considerations: I fully agree in principle, but there's no untrusted wired devices in my home, so I don't think I need to be that strict.

The only reason why I want guest (WiFi) traffic separated from my own (trusted) traffic is the few occasions where we would give friends/visitors temporary access to our network for free internet -- nothing else.

Kind regards,

Ralf

6

i will leave the 'virtual'-topologies of the various network subcomponents to you...

if you have trouble with virtialisation then do it physically with small 'test' topologies... just takes more time...

the point is, to break down each element and test it in isolation...

re: tagged vs untagged... don't overthink it too much now TESTIT under realworld conditions... you will quickly find the answers you seek...
(but if you really must fill some underlying sauce... suggest you websearch for some cisco ~ ccna docs with keyword 'native vlan' ymmv)

1 Like
7

a guest ssid with wifi isolation on separate subnet should really be sufficient but VLANs would enforce that.

Also personally? Just get some decent wifi APs. be it 2nd hand off ebay. Proper APs are a world of difference to soho routers with wifi. I replaced my router wifi with a ubiquiti AC-Lite and its been night and day difference.

I highly suggest having a read of this. It is an older article but shows the complexities of a "pro" home network. In short? plan it like a corporate network deployment and you should be good.

1 Like
8

hi,

in virtualized environment you can fire up owrt x86 images in couple of minutes, and can easily test how the network would look like defining mwan, VLANs etc etc. and obviously you can add clients to see end to end scenarios, e.g. client1 on router1 via vlan x can or can not reach clientN on routerN. you can simulate master router with DHCP/DNS and many dumb AP scenarios. if basic routing is working then you'll know what to do in real life and can add wifi part which should be easy at that point.

just do not use the default bridge mode, rather custom "internal lan" mode so the test traffic remains in the virtualized environment.

it is a safe and easy way to test whatever you want (new release, new setup, new package). so @anon50098793 's suggestion is really a useful one.

1 Like
9

This part is true.

This one however not really, at least not the 'easy' part. You have to be quite familiar with both the topic at hand, and your hypervisor to simulate more complex network scenarios properly - it's not as simple as spawning a desktop operating system which just wants internet from a single virtual network interface, you have to define your network properly (and within the constraints of your virtual environment), twice - once for the hypervisor, once for the VM (OpenWrt).

Testing network setups is easier on real hardware (and be it an underpowered, old device that just meets minimum system requirements), unless you're very familiar with OpenWrt and your virtualization environment.

1 Like
10

some basic knowledge of your virtualization solution is needed of course, but simulating cables which actually what you need to do, is quite easy in any of the hypervisor i know - so let me disagree with you: it is not complex as you suggest.

having spare hw can also work if you don't mind sometime you have to reset/go back to factory image/re-install owrt and most importantly if it is ok for you doing screen-less.

either way, it's your personal preference and your available options - so up to you obviously. but i do think VM based setup can be a really nice alternative and it costs you nothing :wink:

1 Like
11

That is crystal clear -- I'm well acquainted with that approach and would have done it anyway... :slight_smile:

Guilty, your honor -- of "overthinking"... :wink:

But indeed -- I guess I just have to get started. I still have two (older) routers laying around, I will probably use those as a mini-lab and start playing with them...

Thank you.

1 Like
12

No, I don't think that would be sufficient. This way "untrusted" traffic (from my guest SSID) and "trusted" traffic would end up in the same LAN, so "untrusted" traffic could reach my NAS devices and other "valuable" resources... Definitely not what I want...

Actually, that AP is exactly what I still have laying around... But TBH I couldn't see much difference to my Netgear R6220 or my Linksys WRT1200AC... Where do you see the big difference?

Thanks for that article, I'll give it a read... Yeah, "plan like a corp deployment", that's exactly why I'm asking countless questions here... :wink:

Thank you.

1 Like
13

Full isolation with vlans and firewalls. Lee uses that for his IOT setup in the article.

ah you have a newer SOHO. my old soho router was a bt hub 5. it managed ok but against real concreate walls it stands no chance against the AC-Lite. Its also quicker and further range.

Proper planning prevents piss poor performance :slight_smile:

It is an older article but the premise still stands. Obviously now we have newer equipment like wifi 6. But there will be parallels you can draw from.

1 Like
14

That's an interesting idea... But I have some doubt... Would it really work well? I mean running an x86 image in a VM itself should work, but "what" will emulate the underlying hardware? I mean the normally underlying hardware that is missing here? It's very special hardware that's not found on a normal PC, and that VBox might simulate successfully... Or am I missing anything here? :confused:

15

Actually one of the old routers I still have laying around has a USB console (I soldered it in), so it would be nice for experimenting...

I'm too scared that all my testing would be invalid, because these VM-based setup would not 100% transfer to real devices. Sorry for being sceptic, but it's also because I simply lack the experience with setting up virtualized routers. :wink:

16

Exactly, VLANs and firewalling is strictly required for what I want to accomplish.

Definitely agree with that. :wink:

I'll check it out -- thanks again.

1 Like
17

the point is:

virtualized setup is obviously not for testing hardware which by nature makes no sense, it is for testing sw features, capabilities.

  • you want to understand how vlans are working without jeopardizing your "production" network -> test it in VM,
  • you want to test if sysupgrade will work between (major) releases -> test in in VM ... what a surprise was when i found out image sized changed so my partition tables would be messed up totally,
  • you want to test major changes like swconfig -> DSA -> test it in VM ... since DSA was introduced every other day a new topic is being opened asking the same: what happened because after upgrading to 21.02.x nothing is working ... just because some did not read the release notes about DSA and was not prepared,
  • you want to test a new package your are interested in, or want to find optimal configuration -> test it in VM,
  • you want to test firewall rules, DNS customization without loosing your internet access -> test it in VM,
  • you want to test which SQM/QoS solution is best for you -> test it in VM.

for example for me the switch from swconfig to DSA was a major concern, and I only upgraded to 21.02 after i tested if and how can the same setup configured with DSA, as i did not want to test it on the fly losing my internet connection (during lockdown it was/is a critical component i don't want lose) so i was/am using VMs. it is very convenient ... for me at least. the best part is it is totally free and totally customizable (i can easily test if living with with a single port router, or something with 2 ports is enough or definitely need 4 ports). And the best of best is: i have screen+shell access all the time and if i screw up i can still access the VM, or worst case easily rollback/reinstall.

this is an option, maybe it is not for everyone ... but it works for me.