SOHO Network Topology and the like; care to share?

Would anybody be interested in discussing and sharing their network topology of SOHO deployments and the like?

I am new to LEDE. My current topology is very simple.

Internet > Tomato Router > Private LAN (Trusted; Wired and WiFi) > VLAN (Untrusted; Wired and WiFi)

In browsing through the LEDE documentation I found this page. It got me thinking. I would like to add additional security and features (services) without exponentially increasing complexity.

I’ve attached an (see below) of what I have in mind. My needs are pretty modest. The cable modem is rated at 60Mbps. I am planning to use a 100Mbps LEDE device as a first layer of protection; router & firewall. LUCI and all services except firewall, DDNS and SSH would be disabled. Port forwarding / routing would go to two devices. One running something like IPFire or OPNsense to provide firewall, web proxy, IDS, virus scanner, VPN, NAT etc.; the other one running LEDE to provide firewall and routing for a DMZ to host web services, etc. (but this is more like a future project).
The IPFire / OPNserver device would provide DHCP and DNS for the untrusted and trusted zones. The trusted zone would host wired and WiFi devices that run either Windows or some *nix flavor and would be comprised of laptops and desktops and some NAS to provide local services like Samba, UnPN, etc. and some media players like Volumio or Kodi. The untrusted zone would host all IoT devices like Android, iPads, AppleTV, IP cameras, Roku, etc. and may feature a guest SSID. Each zone would be a separate subnet.
Ideally I would like to be able to access the untrusted zone from the trusted zone to manage some devices in the untrusted zone (one way only). I am not sure, if that’s possible (maybe VLAN)? Also I would like to segregate each device hosted in the untrusted zone, i.e. no device should be able to access the other. I’ve done this at work with some Meraki APs, but it’s kind of a black-box affair. It’s not entirely clear to me what’s happening behind the scenes.

Any way feedback would be appreciated; and maybe share your setup?

Thanks

Network Topology Olympia LEDE & IPFire

Duplicate of: Discussion of network topology

I think this adds layers of complexity and performance degradation that seem unhelpful, without really improving security as much as you might like. Some minor changes are probably in order. I'm assuming you've got important security concerns.

What were you planning to run IPFire on? I assume some sort of x86. I think putting that out in front makes good sense, at this point you can run very high quality bandwidth shaping and bufferbloat protection. You're talking about that device having 3x gigabit ports. For redundancy and reliability it makes sense to bond those ports into a single bonded interface, and then segregate the Wan, Orange, Blue, and Green networks by VLAN tags. If you do this and have a cable fault it reduces the throughput but all the networks remain connected. To do this you need a capable smart switch. My recommendation is:

Which is available for about $100.

Do you not have a wired connection to the cable modem? Is that why you have the LEDE device out in front? I think that's a big mistake, wireless connections will float up and down in quality all the time, and you'll never get good latency and bandwidth management performance, Plus you're talking something like double NAT at least. If it's your only option because the modem is in a different building or whatever, then I'd suggest a layer-2 bridging device with a directional antenna and a permanent mount.

Now, maybe you're concerned about the IPFire router being compromised and then the keys to the castle are gone. So you want additional protection. The two brick wall devices on the far right and/or the DMZ one which run LEDE are reasonable to put in if you have that level of security concern.

However to reduce the chance of compromise, run those extra devices in Bridge mode, with bridge iptables enabled. Have all the management services (Luci, ssh, etc) listen on a special management VLAN.

Turn on 802.1x on one port of the Zyxel switch that is an access port for the management VLAN. Also have the access ports for the Blue, Green, Orange vlans use 802.1x and install certificates on the LEDE bridges. Now, the only device allowed to feed packets to the LEDE bridges is the Zyxel and vice versa. And the only way to admin the IPFire or LEDE devices is to walk up to the Zyxel and plug into a special port with a device that will do 802.1x authentication to get access to the management LAN. I think that's probably a very successful topology for your purposes.

EDIT: looked at the manual for the zyxel switch it will require authentication for its ports, but it won't authenticate itself to the LEDE switches. That's ok, just one way auth is better than nothing. Further EDIT: physical security for the links between the switch and the bridge filters and the router is important. IF no one can monkey with either end of the wire, then you have a much better assurance that no one can inject packets.

1 Like

Further thoughts:

There's really not a need to have 3 separate LEDE bridge-filters. Run a single bridge filter that participates in multiple VLANS. Yes this reduces your isolation marginally if a massive compromise can occur, but really, someone hacks your IPFire install, hacks your port security, and hacks your ssh into the LEDE device... are you really that big a target? Much more likely you're trying to keep compromised apps installed on Android devices from automatically compromising machines in your LAN right? You have to decide what your credible threats are. all bets are off if you are housing billions in bitcoin or some such thing.

1 Like

I don’t want to overstate my security concerns. They really are moderate. The motivator to do this is an impending move. That coupled with wanting to try out some additional services like a Web Proxy, Virus Scanner, etc., but only, if it improves security without adding layers of complexity that become too difficult to manage or setup. It’s balancing act. I anticipate some of this will be a challenge for me, since network architecture, firewall setup, VLANs, etc. is not really my forte. So thanks for the feedback!

I am not settled on IPFire. I once installed it as a test. It was fairly straightforward, but I found the English speaking support forum is not very active, which concerns me. Do you have any experience with it or OPNsense?

I would be running IPFire on a full size desktop. It uses a half-size dual port NIC and a built in NIC. It would be positioned directly after the first LEDE firewall / router:

Cable modem > LEDE firewall / router > IPFire.

The reason for this I glanced from the documentation that I referenced in my original post. The author suggested to turn all services off on that LEDE firewall / router including LUCI as to limit the attack surface. So I kept it in my design. But maybe that just adds a layer of complexity without improving the security? A typical IPFire setup based on the IPFire documentation has the device directly connected to the modem:

Cable modem > (RED) IPFire > LAN (BLUE, GREEN, ORANGE).

The color scheme is to denote trusted (GREEN), untrusted (BLUE) and DMZ (ORANGE) zones. Typically during setup one assigns each zone to a NIC. I believe it’s possible to bond NICs in IPFire to provide redundancy, but I have no first hand experience with it. I also believe it’s possible to assign zones to VLANS, if the hardware lacks the necessary amount of NICs to accommodate all zones (or more).

BTW, the cable modem would be directly connected to the IPFire or LEDE via a wired connection; it’s not a wireless connection. The modem itself does not provide any wireless or routing functionality. So I guess the first question at this point is: is it really necessary to add LEDE between the cable modem and IPFire? I believe you recommend one or the other not both; otherwise I’ll be doing double NAT?

Let’s move on to the other three LEDEs to the right of the IPFire device. No I don’t see myself as a high risk target; no State secrets kept on my network. Maybe I need to think smaller, simpler.

Thank you for introducing me to the concept of working with 802.1x.

Access to the physical devices is restricted and security is guaranteed. I think I will skip the 802.1x authentication altogether, since it implies that devices could only me managed by being physically connected to the switch on an assigned port, if I understand correctly. I prefer to be able to manage all devices over the network. This should be possible via VLANs in combination with the managed switch. I will need to think about this some more.

Nah, you’re right I am a small fish. Unmanaged devices that seldom receive updates are my biggest concern, i.e. KRACKER and some of the more recent Android exploits, media devices, IP cameras, etc.. Again I am mostly motivated to re-think my security right now because I will move soon; I own several consumer grade WiFi routers that are compatible with Tomato or LEDE; and because I am interested in some of the features IPFire has on offer. I appreciate your recommendation of the Zyxel switch. I have an ancient Dell PowerConnect 5324 that I believe supports VLANs.

I will draw up a new draft based on your feedback. Thanks for that!

Sure, I'd be happy to comment on the next draft as well. Here's the summary of what I'd consider right now:

Modem -> Smart Switch VLAN10 -> IPFire/OPN/Etc

Also
SmartSwitch VLAN 1 -> LAN
SmartSwitch VLAN 2 -> DMZ
SmartSwitch VLAN 3 -> IoT Network

Then give the IPFire vlan devices for 1,2,3,10 and assign those vlan devices to each of the IPFire colored zones.

Your IPFire/OPN box is then a router between vlan 10 which is wan, and each of the vlan 1,2,3 which are various lans.

Start with that, it's pretty good security, and then decide whether you want to add something else. If so, I think your biggest attack concern is the IoT devices and their factory firmwares, and so adding a LEDE device as a bridge with a custom firewall that offers no services itself could be beneficial. You can prevent IoT devices from calling home to china, and/or ever sending packets directly to your IPFire device.

SmartSwitch VLAN 3 -> LEDE Custom Firewall Bridge Box -> IoT devices

would improve that security because it would be more difficult for a compromised factory IoT firmware to attack your main IPFire/OPN box.

The LEDE box out front between modem and ipfire is a performance concern and I'd generally eliminate it in favor of just being very careful with IPFire/OPN settings etc.

One thing you could do though is to use port-mirroring on the smart switch to set up some kind of logging / intrusion detection system. That might be able to run on some low-end older router and just log events to a USB key. Basically a device with a NIC in promiscuous mode plugged into a special designated port and just watching packets and logging.

Beyond that level of security lies I think more trouble than it's worth. I will say though, offsite backups!

1 Like

Ok, here’s my new draft. I’ve color coded everything and noted the functionality each device (Managed Switch, Unmanaged Switched, IPFire, LEDE, etc.) should provide.
I assume that theoretically, were it not for a limited number of ports, any LEDE device could function as a Managed Switch. I am not a 100% sure, if VLAN Guest would function properly the way I have it logically mapped, but I think so. I also forgot to mention that I will be using a Wireless Bridge to provide network connectivity to a remote location. It’s an Engenius ENS500-AC that will be running in WDS Bridge Mode. It supports VLANs, but I haven’t tested it yet. I understand VLANs in theory, but I’ve never worked with trunked devices, so this will be an interesting adventure. BTW, did you say you had experience with IPFire?

Cheers

Network Topology IPFire revision 2

What you have laid out here seems to make a lot of sense at least at first glance. I don't have direct experience with ipfire but I did recently help another person in this forum who wound up using it successfully and did at least review some of its features. It should do what you need here.

It could be mentioned that you are planning to use a lede-based device as smart switch on the low end in front of your trusted Network. This could in fact have iptables filtering as a second layer if you felt it was helpful. Similar to what you do for iot and untrusted.

I would also be concerned about physical security of the LEDE device on the far end of your wireless bridge. If it is compromised then packets can be injected to your trusted Network.

1 Like

Also I think that the line currently labeled as a yellow truck that goes to your green trusted network should only carry the green traffic it should not allow tags for other vlans. Typically this means it's plugged to a port on the switch that is only on the green Vlan. Actually the same is true for untrusted and guest, and the dmz, those should be the only traffic on those lines. You haven't made That explicit but in general no line should be allowed to carry traffic for networks it's is supposed to be isolated from.

1 Like

I will incorporate that into my next draft to consider as an option.

The remote location is less than 100 feet away and secure. Nobody but myself will have access to physically connect to the LEDE device. Maybe this device should also do iptables filtering?

BTW, WiFi MAC filtering will be enabled on all LEDE WiFi APs. I understand MACs can be spoofed. But I guess that’s the best I can do.

I think I was confused by the concept of trunk vs. access. I will update my draft and post tomorrow.

Thanks for taking the time to check it out.

Yeah, to me "trunk and access" is kinda misleading terminology. Here's how I'd characterize the basic concepts:

  1. Membership of a port
    A port that is a member of a VLAN will allow ingress or egress of frames for that VLAN. So a port should only be member of VLANs that are supposed to pass over the wire either in or out. Remove membership to block illicit frames from going through the port.
  2. Tagged Vs Untagged frames
    A port can accept and xmit either only untagged, only tagged, or both types of frames.
  3. Port VID
    For untagged frames received on a port, they are essentially tagged internally with the Port VID. For frames that are supposed to leave a port untagged, they are in essence only frames from the given VID whose internal tags have been stripped.

So, make sure each port has membership in the minimum required set of VLANs to do its job. And if the port needs to accept untagged frames, make sure that the Port VID is set to whatever VLAN you want those untagged frames to be interpreted as part of.

1 Like

A better option might be to use WPA enterprise on the trusted WiFi. Give each person/device a separate access credential. It doesn't look like IPFire has a RADIUS server available, but you can run a freeRADIUS server on your trusted/green LEDE device to do this authentication.

1 Like

Also, depending on how pointy-clicky you need things to be, it might be better to install a very limited standard distro, something like Debian or Arch or the like in the "central" firewall role. A stock "server" Debian install with firehol would give you a very good firewall/router, and then you could add whatever packages you need for additional services, like squid, or freeRADIUS, or NAS services etc.

1 Like

I will keep this explanation for reference; and watch a couple more YouTube videos.

I'll put it on my list as a future project. Thanks for mentioning this option.

It had crossed my mind, but I thought, man there must be a distro out there that brings all the great features together, so I don't have to reinvent the wheel. That's why I initially thought IPFIre would be a good candidate, but the more I look at it, what I initially thought was a firewall+ with a GUI, is really not that flexible, unless you want to work from the CLI. At least that's my impression. If you go defaults during the install, I am sure a person would be fine; but link aggregation alone I believe is not covered in the GUI or during setup; and there's only a limited number of VLANs one can use. At least that's according to a post, I 've read somewhere. I guess we'll see. I think I will try OPNsense first.

Yeah, OPNSense seems reasonable, it's based on FreeBSD and I have no experience working with FreeBSD so I probably wouldn't choose it, but that's not a reason you shouldn't try it :wink:

Just took a look at this. Pretty sweet.

yep, I use firehol for my firewall on a Debian box, and I'm extremely happy with it. And furthermore, I understand exactly what my firewall allows or does not allow because of it.

Well, I’ve ordered the Zyxel managed switch; but I only got the 8 port one. Although the 24 port is quite the better deal. Hopefully this weekend I will have some time to play with it.

I’ve uploaded a new draft that shows each VLAN on its own port. Except for the trunk connection between the managed switch and the IPFire.

I’ve reread what you wrote above about 802.1x, but I am not sure I have a firm grasp on it. So I would use one port on the Zyxel and assign it to VLAN Admin and enable 802.1x. Then I would enable 802.1x on each VLAN port that that uses a network device that needs to be managed, i.e. IPFire, LEDEs, etc. Those devices could then only be managed by connecting with a laptop to the VLAN Admin port on the Zyxel; those devices would authenticate themselves through the 802.1x protocol to the Zyxel, but not vis versa? How do I know my laptop supports 802.1x? Would this mean that the VLAN Admin would need to be assigned to each VLAN port that also runs VLAN Green, Blue, etc.?
What are my options, at a reduced security cost, if I want to manage my Zyxel, IPFire, and LEDEs from a laptop residing on VLAN Green?
Sorry, these are lot of questions and maybe some of this will become clearer once I get hands-on.

Cheers

Network Topology IPFire revision 2