I’m planning to add a second WAN as a backup. WAN2 entry point is not where the router is located, but I have a switch there. So I’m thinking to pass WAN through the switch as a tagged VLAN and terminate it to L3 at the router. Problem is, the switch is already used to deliver existing local VLANs to that location.
LAN <--> Router <--> Switch <--> WAN2 (WiFi)
^ ^
| |
| |
v v
WAN1 LAN
This is basically the standard router on a stick configuration, only with WAN involved. Is this kind of configuration considered inappropriate or insecure? Looking for opinions. There is of course L2 isolation, but “mixing” WAN and LAN on the same wire makes me doubtful (VLAN hopping?). Bandwidth is not a concern as WAN2 is only 25 Mbps.
The switch is actually a hAP ac2 acting as a switch. My plan is to connect its WiFi to an external wireless network as a client, add the WiFi interface to the bridge with VLAN filtering as an access port with a dedicated WAN VLAN, and pass the traffic over trunk port to the router where the firewall is configured. Given that ac2 can work as a router itself, I could set it up with WAN2 IP, a firewall, and point the main router to use it as a gateway for its backup WAN. But it would mean another NAT layer and dealing with another firewall, something I would prefer to avoid.
There is no reason why the hapac acting as a switch from a main router cannot vlan a second wan to the router.
There is one trunk port to the router from the switch.
One of the vlans already in play to the switch is a management vlan where the hapac gets its IP address from.
So lets say we have vlans 10,20,30,40.50 and management vlan 99. /ip address
add address=192.168.99.2/24 interface=vlan-mgmt network=192.168.99.0 comment=“switch IP address”
The management vlan is the only vlan needed to be identified on the switch and the only vlan-id with bridge tagged in /interface bridge vlan settings.
For transferring the WAN2 through the switch lets say its on ether5… on the router create a vlan 200 ( no dhcp, or pool required etc. )
ON hapac (ether1 being trunk port to router)
@anav, thanks for taking time to respond! I wasn’t looking how to do it, no questions there. I would like opinions on whether such setup is generally discouraged, or the opposite, if people use it in real world.
This is a fairly insightful question. Just throwing in my two cents.
First off, what you describe is a fairly standard setup and there is nothing wrong with it per se. It has a bad reputation however because of several reasons.
You are clearly aware that there is some level of security risk by mentioning e.g. VLAN hopping. This is a major point: this sort of setup makes your switch fabric part of the perimeter of your network. Usually in today’s climate the focus is on security in depth, zero trust, etc. - which are nice concepts - however there still is a difference (or maybe just a perception of such) that the internal part of the network is less exposed to attack than the perimeter. This means:
you probably have to make sure you monitor threats and update the firmware of your switches as often and as diligently as on your main firewall device
ensure a proper setup for your switch fabric especially with regard to the wan you’re transporting - while I don’t underestimate your technical capabilities, this can be challenging even for experienced admins, simply because there are quite a few settings involved:
of course VLAN filtering and admitting only untagged packets,
also setting the port as “edge” - you don’t want to send or receive BPDUs
disabling MVRP - the wan port should not be able to request other VLANs to be assigned to the port
disabling any sort of discovery, LLDP, etc. on the switches as well
For these reasons the usual recommendation (especially if you have to pass any sort of certification or review) is to forego this sort of arrangement if a suitable alternative exists.
While this is definitely the advice, I’m not sure I agree with it. For these reasons:
I think some of this advice is motivated by a desire to reduce the amount of paperwork or to stick with familiar architectures. While these are valid reasons, they should not be the main or sole driving impetus behind any engineering decision.
If you are willing to stick to a single manufacturer (as you seem to do with Mikrotik), updating your devices should not pose any real difficulty.
I think often the worry is regarding receiving updates or advisories from multiple sources, and generally there are licensing issues with regard to firmware updates that many organizations are much more willing to slip on with regard to switches. Again, if you stick with Mikrotik, these concerns don’t really affect you.
If you already have any sort of “cloudy” deployment (e.g. VMs that you don’t completely trust) then you are already depending on your switches to provide the necessary security, so you’ve already done your homework (or should have.)
If you operate a network where “random” devices are allowed, be they what is referred to as IoT, or guest/visitor devices, than again you’re already exposed to any threat that might come through attacks on your switches.
I dont see any additional security risk setting up the switch to take the ‘raw’ wan to a router via a vlan for termination on the router.
Ensure all bridge ports are set with ingress filtering and appropriate frame types.
Ensure bridge has frame types set to tagged only.
@ LURKER: I do not see where any additional risk is being generated???
[]
But it would mean another NAT layer and dealing with another firewall, something I would prefer to avoid.
[]
if you plan to add an additional internet wan - most likely you need to configure nat and firewalls.
if you meant private wan ie. office to office private leased line - your new wan vlan setup is not uncommon. although probably some would say not ideal or not scalable.
just be aware that layer 2 filtering is trickier than layers above it.
Thank you all for responses. This is nothing mission critical, just a backup for my home Internet (which is also used for work). But I like to follow best practices whenever possible.
@lurker888, all good points, and they corroborate my intuitively cautious thinking. Agree with your disagreement to the listed points, but I also understand the usual cybersecurity notion of reducing the attack surface as much as possible, even if it doesn’t seem all that valid or is ignored in other similar configurations (like IoT and untrusted VMs).
I will forgo this idea and use the tried and tested L3 approach.
I already have a firewall and NAT on the main router and was thinking of just adding the second WAN interface to the WAN list, same rules. Now I will need to set up a firewall on the secondary router also (no NAT needed though), but it’s pretty much set-and-forget.
@anserk: I disagree with the usual thinking, but I also think it’s important to understand someone’s point before dismissing it. (And although this is not a valid argument, I find the usual cybersec guys to be under educated and basically parrots that spout marketing or dogma.)
I think you’d be very well served with a VLAN solution. The usual risks are shoddy switch makers, of which MT in my estimation is not one, and bad config mistakes, which I will assume you will not make. You are completely right that at the speeds you quote you basically have the luxury of choosing whatever tickles your fancy, including even EoIP or VXLAN transporting the data, but I think that would be going overboard…
@anav: There’s nothing inherently wrong with doing this. The risk comes from having a bad (insecure by design or implementation) L2 fabric exposed. You shouldn’t have one of those, and if you do it should be fixed. But you can’t really deny that many are insecure.
For example I’m quite happy to use a TP-Link Easy Smart switch (TL-SG108E) in a pinch for a desk or powering some APs (that would be TL-SG108PE), but it has very serious problems, like not having a proper management VLAN, which means its admin web interface is accessible from all of them, having a DHCP client on all vlans, etc. so for local use it may be fine, but I would never dream of exposing it to a WAN. (And just a bit of information: yes, they know about it and aren’t going to fix it because it’s all by design.) But they’re dirt cheap
Exactly my experience with cybersec. I can’t believe this is such a common theme, I thought it was just our company. Even well-established organizations are prone to these issues. I remember filing tickets with CIS to question some nonsense in their Red Hat security hardening guides, and I don’t even claim to be an expert, just a guy with some common sense.
Funny that you mention TL-SG108E, because I have the exact same switch. I discovered its flaws right after I purchased it several years ago and even left a product review, warning other users. It’s switches like this that cast more doubts on L2 isolation. By the way, the inexpensive Netgear models suffer from the same issue, but it’s not really about the cost either. Much later I found out Zyxel has switches in the same price range that have a proper management VLAN.
