OpenWrt on Raspberry Pi 4B without USB3 Ethernet dongle

Installing and Using OpenWrt Network and Wireless Configuration
1

I’ve now been running OpenWRT on the raspberry Pi 4B for three weeks with a little setback during the first week. Initially, I was using a USB3 to Gigabit Ethernet adapter based on the Realtek rtl8153 chipset, using the standard 8152 kmod present in the OpenWRT kernel. My family was complaining about problems with video, so eventually I decided to do something about it. I always hated USB3 Network adapters. I use a MacBook Pro, and I noticed that the official Apple Thunderbolt-to-GigabitEthernet adapter daisy-chained with the TB3-to -TB2 adapter beats any USB-based Gigabit Ethernet adapter. USB introduces flakiness into the Gigabit Ethernet connection. Sometimes USB-based Gigabit Ethernet adapters function at the line speed of 940 Gbps but a few minutes later the throughput could be reduced by 1/3 or even by half. I’ve tried multiple devices with rtl8152, rtl8153, and rtl8156 chipsets, and they all have this problem. On the other hand, the TB-based Gigabit Ethernet adapter is a direct PCI bus to the chipset without any USB3 bus involved. Unfortunately, Apple never bothered to update their adapter from TB2 to TB3; hence, two daisy-chained adapters are required on newer Macs, as described above)

So, knowing all of that going into the OpenWRT on the Raspberry Pi4B experiment, I actually expected that a USB3 gigabit Ethernet network adapter could be problematic, and my family let me know it was actually the case.

My solution was to eliminate the USB-based Gigabit Ethernet adapter altogether. Of course, the most obvious downside to that solution is that the 2Gbps maximum theoretical bidirectional throughput of two GigabitEthernet ports used as LAN/WAN interfaces would be halved to 1 Gbps of maximum theoretical bidirectional throughput. However, curiously enough for a home environment the real-life throughput would not be halved but reduced by the amount of the bandwidth used in the upstream (from the home LAN to the Internet) direction. For asymmetric Internet connections the math is even better. For example, if your Internet bandwidth is 1Gbps down/ 40 Mbps up, then you are likely to enjoy up to 900 Mbps download speed while using just one physical interface on the Raspberry Pi 4B. Just make sure you configure SQM correctly with 900 Mbps download bandwidth and 40 Gbps upload bandwidth for a total of 940 Mbps (which is the maximum that the Raspberry Pi can push in one direction on a physical interface).

So, by eliminating the USB to Gigabit Ethernet adapter you are not losing a lot of download bandwidth but you are improving the quality of the routing system dramatically by jettisoning the flaky USB-based Ethernet controller.

So, how do you configure this? It’s really easy. All you need to do is create VLANs under the on-board Gigabit Ethernet controller (usually eth0). As an example, eth0.10 (VLAN10) is used as the WAN interface and eth0.20 (VLAN 20) is used as the LAN interface. I would also create another interface in OpenWRT, call it RECOVERY, associate it with eth0 and assign a static IP to it. This interface would be used for troubleshooting/recovery purposes allowing a direct connection with a computer without having to configure VLANs in a computer OS. That’s all! You can even make this change in /etc/config/network and then reload the network daemon: /etc/init.d/network reload.

So now that we have configured OpenWRT with two tagged VLANs and matching VLAN SVIs (LAN and WAN), we need a VLAN-aware switch to assist the Raspberry Pi in using the same physical interface for both LAN and WAN SVIs. It’s absolutely not a problem, though, because TP-link has very inexpensive 5-port and 8-port Gigabit Ethernet Easy Smart switches (they are simplified managed switches that have VLAN and some QoS capabilities). There are non-POE and POE+ versions of these switches. The non-POE 5-port Gigabit Ethernet Easy Smart switch costs $25 on Amazon. You could get a POE+ version of this switch for $60. Add a POE splitter for another $17, and you can power your Raspberry Pi from the POE+ switch and free up one outlet on your UPS. You can also buy another POE splitter for your modem to power your modem from the POE+ switch and free up another outlet on your UPS. Since I'm posting links to specific devices here, I would highly recommend the Argon Neo case for the Raspberry Pi 4B used as a router/firewall. Do not buy the version with a fan. The case passively cools the Raspberry Pi used as a router/firewall with no issues whatsoever.
Note: The other Argon case (Argon One) has a circuitry that prevents the Raspberry Pi from automatically powering up after the power is lost and then restored, so even though the Argon One is a very nice case and should be considered for the Raspberry Pi used as a desktop for sure, it is not suitable for the router/firewall use case

So, this is what you need to do on the switch:
Port 1: assign VLAN 10
Port 2: configure as 802.1q trunk
Ports 3-5 (or 3-8): assign VLAN 20

Connect your modem into switch port 1. Connect your Raspberry Pi 4B’s onboard Gigabit Ethernet controller to switch port 2. Plug your other wired devices (including your Wi-Fi AP) into ports 3-5 (or ports 3-8). If you want to further segment your network into additional VLANs, create more SVIs (interfaces) in Open WRT and assign them to eth0.X, eth0.Y, etc., where X, Y, etc. are VLAN numbers. Then, assign matching VLAN numbers to certain ports in the range 3-5 (or 3-8). If your Wi-Fi AP (or other device) that you want to connect to the switch is VLAN-capable, then configure the port on the switch to which this device is connected as 802.1q trunk but MAKE SURE that you disallow VLAN10 out of that switch port. This step will ensure that the traffic from the Internet arriving in switch port 1 on VLAN 10 can only get to switch port 2 where it will be received by the OpenWRT’s WAN interface (eth0.10) so that this traffic could not leak into your LAN bypassing the OpenWRT firewall.

If you already have a managed VLAN-aware switch, then you don’t even have to buy a TP-Link switch. As long as you have two spare ports on your managed switch, configure one of them with VLAN 10 to connect the modem, and configure the other one as 802.1q trunk for connecting the Raspberry Pi 4B. Then, configure all remaining ports for VLAN 20 (or any other VLAN ID other than VLAN10 that you configured in OpenWRT to further segment your LAN). Just make sure to disallow VLAN 10 from any existing or new 802.1q trunk port on the existing switch to preclude the Internet traffic from leaking into your LAN bypassing the OpenWRT firewall.

I hope this solution will come in handy to those who decided to use their Raspberry Pi 4B as the OpenWRT firewall.

Now that the Raspberry Pi Foundation has announced Compute Module 4 and the official IO board with a PCIe x1 port, it will be possible to use a PCIe based secondary Ethernet interface (single 1 Gbps, dual 1 Gbps, quad 1 Gbps, single 2.5 Gbps, or dual 2.4 Gbps) for the bidirectional throughput of up to 5 Gbps. But as of now, there are no cases available for CM4 mounted on the IO board, and having the naked electronic boards used as a router is not an appealing solution. So, for those with symmetric Internet connections of up to 500 Mbps or for those with asymmetric connections of up to 1 Gbps downstream, the solution I’ve proposed here should work really well. At least it’s working well for me. With the SQM configured, this is the best home firewall solution bar none. Even pfSense can’t compare because of how effective SQM is as a QOS algorithm. And I’m saying this as a network engineer with a 20+ years in the industry who has been designing QOS solutions for very large enterprises for many years.

10 Likes
2

Nice write up.

A big caveat on the TP-Link SG108E switch is that the management server listens on all the VLANs. This is a bad design but it can be worked around if security isn't critical in your application. The important workaround is to turn off the DHCP client in the switch and set it with a static IP in your LAN range. If the DHCP client is active, there will be a race condition where it may take your single public IP from the cable modem-- which will break the network.

The Zyxel GS1200 series is at a similar price point to the TP Link and has a much better user interface. Unfortunately they don't offer one with PoE. The GS1900 series is a lot more professional. Also there is work on porting OpenWrt to certain GS1900 models.

3

Is this a problem with SG-105E switches?

I hear that if one wants to get an SG-105E, it should be hardware version 3 because some of the improvements with VLANs implemented in the latest firmware only apply to hardware version 3.

Also, a managed switch should never stay on DHCP-assigned IP address. The management IP should always be manually assigned. If the user knows enough to be able to manage a switch, the user should be able to assign a static IP to the switch. I can see that the DHCP client feature is necessary for a managed switch without a console port so that the initial IP address could be assigned by DHCP for accessing the switch initially, but as soon as the switch is accessed, the user should change the IP to a static one and turn the DHCP feature off.

In my case, I am using a Cisco enterprise switch, so my advice to get a TP-Link Easy Smart switch is based purely on the very reasonable price point. Also, this is obviously for home use (and perhaps very small business use), so there’s no need to buy expensive switches. As long as these TP-Link switches serve the purpose, they should be considered. The whole OpenWRT routing solution based on the Raspberry Pi 4B can be had for as little as $90, including the Raspberry Pi board, the case, the power supply, the switch, the SD card, and all required Ethernet cables. Or, if one goes with a POE+ switch, the total price could be a little over $145.

At these price points, I would go as far as to recommend getting two Raspberry Pi 4B boards, two power supplies (or a power supply and a POE splitter), two microSD cards, a couple extra Ethernet cables and two SG105E switches just to have cold spares to preclude any prolonged Internet outage in case one of these parts goes bad. Even at double the price (if buying spares), this is still an amazing price point for a home router/firewall solution. To provide a comparison, Ubiquiti is about to release their flagship “enterprise” UniFi UXG-Pro router/firewall for $500, which has less compute power than the Raspberry Pi 4B. And with the terrible customer service that Ubiquiti is known for, one should buy two of their devices to have a cold spare on hand.

2 Likes
4

25 posts were split to a new topic: OpenWrt installation on Rspberry Pi 4B

6

Yes, USB adapters are not great but a lot of people praises that solution here....
RockPro64 + Intel PCIe NIC works great even though all my devices doesn't run OpenWrt right now :wink:

7

My RPi4 with UE300 has been in continuous use for more than 12 months without even a hiccup. So any concerns over reliability can be put to bed by real world data.

2 Likes
8

Sure, one point of data that's great....

9

It's infinitely better than zero. It's also not one point of data as others spread throughout the forum have repeatedly said the same kind of thing. Finally Amazon will deliver a new one in less than 24 hrs, same for an entire RPi4. Also since it only $12 I have a spare on hand.

The idea that reliability is compromised by USB Ethernet is pure FUD

4 Likes
10

OK - I'm going to chime in as well. I stress-tested a UE300 for weeks at full bandwidth without a single dropped packet. In fact, it's been SO stable in real-world production use with a heavy-streaming family of five and two adults working from home that it's outperformed my Ubiquiti EdgeRouter by leaps and bounds.

I read these "knowledgeable" articles about USB "instability" and take them with the generous heaping spoon of salt I think them worthy of. It's very anecdotal and generally can be traced back to cheap-ass knock-off Chinese hardware and/or user error.

There is no "USB dongle problem" with the Pi 4. Full stop. Anything else is FUD.

7 Likes
11

I've just setup OpenWrt on rpi4, painless, attached Cable Matters USB 3.1 to 4-Port Gigabit Ethernet Switch, zero issues, plugged my modem into the USB switch and everything is working.

I can recommend it, but, I'm only using a single device at the moment, so not sure what happens if you try to properly use it.

12

+1 for RPi4 and USB adapter.

2 Likes
13

I'm using a Pi 4 with GigE fiber, the POE hat and a Vantec USB 3.0 to dual ethernet adapter (was $27 when I bought it from that ginormous world-conquering vendor named after a Brazilian river, seems to be slightly more expensive now). It uses the Realtek r8153 module straight out of the box. Yeah, it's more expensive than two UE300s but it leaves a USB3 port free for other purposes; and given that a single USB3 port has a theoretical 5gbps available half duplex, both interfaces get full gigE capability without a problem.

I'm using an OpenWRT snapshot from late March 2021. I mirrored all the packages from that release locally so I don't have to worry if I need to install something later.

It has performed flawlessly, unlimited uptime, no issues whatsoever, maximum throughput to and from WAN and across four local routed VLANs: LAN, WAN, PVT (private, isolated for IoT, reachable from LAN but no route to WAN), DMZ (can reach WAN but no default route to LAN). I'll be posting (in another thread) my easily customizable custom IRQ affinity script and a few other very simple tweaks that help to maximize performance, but basically it just works and never tops 10% of a core on network activity alone, even when speed testing.

4 Likes
14

I’ve now been running the setup described in the first post of this thread for almost 1.5 years. This is the absolutely best internet connection I’ve ever had, and I’ve used many different devices, including Cisco enterprise gear (enterprise routers and ASAs) as well as pfSense.

There is a relatively new inexpensive managed switch option that can be used for this setup. It’s the Ubiquiti USW-Flex-Mini available in the Ubiquiti store for $29 plus tax and shipping. This is a 5-port managed switch that requires the installation of the Ubiquiti UniFi Network Controller application (Windows, Mac, or Linux) to configure the switch. The only limitation of this switch is that it can’t exclude VLANs from the 802.1q trunk port. Therefore, you can’t use this one-port Raspberry Pi solution assisted by this managed switch if you want the downstream LAN device (e.g. Access Point) to support multiple VLANS. However, if you can do with one VLAN per each downstream LAN device, then this solution is one of the least expensive solution to run OpenWRT on the Raspberry Pi 4B without having to use a USB3-based Gigabit Ethernet dongle.

This is how you would configure the USW-Flex-Mini:
Port1: assign VLAN10 (connect ISP modem)
Port2: Assign ALL (aka 802.1q trunk with all VLANs included)
Port3: assign VLAN20 (connect a switch, access point, or a computer). This is your LAN.
Port4-5: assign VLAN20 (for LAN) or any other VLAN ID except for VLAN10. You can use these ports as additional LAN ports (if set to VLAN20) or DMZ interfaces (if set to any other VLAN ID). Again, make sure that VLAN10 is not assigned to any switch port except Port1 (where the ISP modem is connected.

Make sure you assign VLAN10 only to switch Port1 and you assign ALL (802.1q trunk) to switch Port2. Make sure that neither VLAN1 nor ALL is assigned to any other port (Port3, Port4, or Port5).

1 Like
15

This is true, but the operative word is exclude

This is incorrect, at least partially.

It is absolutely possible to pass all of your VLANs through this switch on a trunk port. The nuance here is that you cannot exclude any VLANs on a trunk, so your downstream device (such as an AP) would see all of the configured VLANs at it's interface.

The switch allows you to create either trunk ports (which carry all of the VLANs as configured in the Unifi Network app), or access ports (a single, untagged network).

In other words, if you have 3 VLANs: 10, 20, 30... your trunk will always contain all three. You can, of course, set any port to be an access port for one of those, but you cannot create a trunk that is just VLAN 10 and VLAN 30. So the only issue is if you specifically wish to exclude a given VLAN, this switch is not suitable. However, you can absolutely have multiple trunk ports and therefore it is suitable for APs (as long as excluding a VLAN at the switch port is not a requirement), and you can always have your AP or other downstream device ignore the extra VLAN(s).

1 Like
16

Isn't this exactly (almost verbatim) what I said in my post?

This is patently wrong. The WAN connection is on VLAN10 (based on my first post in this thread). If you assign an 802.1q trunk (that cannot exclude VLAN 10) to any switch port other than the switch port to which the Raspberry Pi 4B's sole physical interface is connected, you will create a Layer 2 path within the switch from the Internet straight into your LAN bypassing the OpenWRT firewall entirely - at least at Layer 2. This is a rookie mistake that people make when they transition from using hardware interfaces to using software (VLAN-based) interfaces on a firewall, assisted by a VLAN-aware switch.

Do NOT under any circumstance create a Layer 2 path from one firewall zone to another one. Layer 2 must be terminated at each Layer 3 software interface for the firewall to be effective and be able to enforce the firewalling of the traffic.

If you ask me, How in the world would WAN IP traffic (Layer 3) connect to your LAN hosts, utilizing the Layer 2 path in your switch that you've created, I will tell you that it's a rather pedestrian task for a fairly seasoned hacker.

Therefore, the USW-Flex-Mini switch can only be used to assist a single-physical-interface host running OpenWRT (or any other firewall) if the downstream LAN devices are to be connected to the switch ports configured as access ports (one untagged VLAN per switch port). If, conversely, the downstream LAN device (access point, another switch, a VMWare ESXi host, etc.) needs to be connected to the switch port with an 802.1q trunk port, the USW-Flex-Mini switch cannot be used in this scenario.

Of course, if you don't use the USW-Flex-Mini to receive WAN traffic on one of its ports, and the function of this switch is to be a LAN switch only, then you can absolutely assign 802.1q trunks (with all VLANs included) to any or to all of the USW-Flex-Mini switch ports with no issues.

17

Yes, but my point was to emphasize the fact that exclude was a key word here. And more specifically, you stated that:

... when in fact you can have the downstream LAN device with multiple VLANs through this switch. The way you wrote it made it sound like it was not possible to have a non-uplink trunk port.

Actually, this is not true, although I will give you that it does depend on the downstream device, and there are some additional considerations. If my downstream device only has VLANs 20 and 30 defined (and 10 is excluded from that downstream configuration), there is effectively no difference between VLAN 10 being excluded at the upstream switch (i.e. the Flex Mini) vs downstream (by not having VLAN 10 defined on said device). The considerations here, of course, assume that the downstream device is considered trusted and is secured. And physical access to said device could then allow someone to tamper with the setup and gain access to VLAN 10 because it was already on the wire. However, if VLAN 10 is not configured on the downstream device, it means that there is no layer 2 (or layer 3) path to VLAN 10 from either of the other VLANs. Period.

I do not disagree with this. But there still would be no layer 2 path if connected to say an AP with VLANs 20 and 30 assigned to SSIDs. The whole point of the tagged frames is that they keep the VLANs logically separated. And unless you have a serious misconfiguration, VLAN 10 would simply be ignored.

Wrong. You can use the trunk port as a downlink. It may not be the best practice, but it will work. And as I have stated above, it will not result in a L2 path from WAN to any of the other VLANs.

Again, wrong. For the same reasons I have stated above... You'd have to set it up as a trunk (which means all of the configured VLANs would be present on the link), but provided you have configured the VLANs properly in the Unifi Network app and the respective interfaces ignore all of the other VLANs, you will not have any L2 or L3 paths between VLANs as a result of using this switch.

ALL of this is predicated on the idea that the WAN is tagged on the trunk port (not untagged), of course.

18

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.