It’s the crypto that drives the load. WireGuard uses one of the lowest computational cost ciphers generally available.
If you stick with MIPS, you’ll need a 775 MHz clock, based on the testing of GL.iNet, who I believe is honest about their results. Realize that if you run anything other essential router services (LuCI is not "essential") or other CPU tasks (such as handling an LTE modem), you won't get the "unloaded" performance on a single-core SoC.
The TP-Link MR200 just isn't powerful enough for more than basic routing. Moving to a multi-core, ARM-based device, or using "something else" for your VPN would be reasonable approaches. Perhaps a single-board computer, like a current Raspberry Pi (crypto speed unknown by me), might be a cost- and power-effective approach.
As you can see, the load of OpenVPN at even moderate rates exceeds what a MIPS-based router can handle.
To get 50-100 Mbps over OpenVPN, you're likely looking at an x86_64/AMD64 solution, with a separate all-in-one as an AP.
Based on that, I'd recommend an ipq40xx-based unit, or one of the faster SoC families, such as ipq80xx, mvebu, or x86_64/AMD64. I don't have experience with the mvebu wireless, but I find the wireless performance of the ipq4019-based EA8300 to be noticeably better than that of the ath79-based Archer C7v2 units I've replaced. Recently someone here posted that Amazon UK had EA6350 dirt cheap (£34).
Ignore the title, but this post has some good starting points:
I, personally, wouldn't buy a cheap, import, such as the "New Qotom-Q150P Fanless X86 Desktop computer Intel Baswell Processor N3150 qual-core 1.6 GHz,Up to 2.08 GHz" you linked, especially from a seller that you have no meaningful recourse from. You can read further opinions on the pfSense boards.
A N3150 is pretty outdated at this point (2015 release).
N3150 single-core Passmark, as one point of reference, is 471
By comparison, a J4105 is 1070
You can buy a SBC like the ODROID H2 for a comparable price, with a J4105, with what I consider good support and, at least based on the other ODRIOD products I've owned, good layout and fabrication.
I will use the TP MR200 to get access to the 4G network and then send all traffic further to the pfsense box.
What settings should I have on the TP MR200 running OpenWRT to make these happens in a good way? I understand the default OS on the TP MR200 is not supporting bridge mode, but OpenWRT can?
It sounds like you considering the H2 for running pfSense, with OpenWrt handling the modem.
I don't run pfSense myself, but extensively run FreeBSD, on which pfSense is built. I've got an H2 arriving today so will be able to comment more on the case in a day or two. I went with the Type 3 case as I'll be mounting two SSDs in it.
My application is probably a lot more demanding than yours as I will be building packages on the box, something that just takes too long on my APU3C4 units. Still, for FreeBSD, I'd recommend that you use ZFS on a two-way mirror (or better). An absolute minimum of 4 GB of RAM, with 8 GB comfortable (2x 4 GB sticks) for day-to-day operation. I've been running on ZFS for years now, and its advantages for stability and maintainability (such as "instant" live snapshots) are significant. 250 GB SSDs seems to be the smallest you can buy from a major manufacturer (I use Corsair and Samsung units), running $40-50 each. https://ssd.userbenchmark.com/ has some interesting numbers for guidance. The Kingston units seem reasonable, especially at the US$20 price point. With low-end drives, mirroring provides a bit more confidence.
OpenWrt can handle many modems quite well. I don't know if it can be configured to have your downstream box deal with the DHCP, but there is the range of options between selective ports to forward (if any) and full, one-to-one "DMZ" to your downstream box. I do something similar where my modem-connected box handles the DHCP, NATs to the fixed address of my next router, provides nftables firewalling, and forwards everything to my inner firewall. This lets the inner firewall use fixed rules, as its interfaces never change address.
I select an OS based on what the application is and how well it fits that application and hardware. The specific application that drove my H2 purchase is a FreeBSD-based server that runs my primary services in jails. The APU3C4 was great for day-to-day use. Some of the packages need non-default settings, so I need to build them myself. The APU3C4 takes tens of hours and, based on my experience with J1900 and 1037U, I would expect this to drop to a reasonable period of time. This means one less box consuming power, even if only 10-15 W.
Yes, Realtek NICs aren't as robust as Intel, Chelsio, Mellanox, or the like. Then again, those cards, if genuine and not "clones", cost more than the H2.
so the old Corsair I had sitting around didn't work. Yes, it's clearly documented, but I failed to check the drive before assembling everything.
Finding a 2.5" SSD to tuck in there next.
Most of the pieces of the Type 3 case are not symmetric, and I somehow managed to get at least two of them assembled "upside down". There are YouTube videos for the assembly of the case, as well as the power switch. The one trick on the power switch video was how to coil the wiring neatly. Here's the pin connections
A fan is definitely needed if you're going to push it hard.
I stopped when the CPU temp crossed 75°C
I'm using a Noctua NF-A9. Running tests on 12 V to start, as I don't have an adapter from the non-standard fan connector yet. I'll try at lower voltages as well. I haven't checked for an EMC2103 driver yet in the OpenWrt tree/packages, though there is one in upstream Linux. BIOS is another option, though I like to run as quiet as I can.
Looks like even 5 V on the Noctua NF-A9 is enough (~67 °C), though 7 V is better (~64 °C).
Note to anyone reading this in the future -- the schematics suggest that it is a 5 V fan that is needed to run off the on-board connector -- to be confirmed
firmware-realtek is needed for a small subset of chipset revisions supported by r8169, in most cases even those that do use the provided firmware don't hard-depend on its presence (the firmware package is hot-patching sub-optimal on-device firmware, often related to interoperability in corner cases, such as long lines or combinations with other quirky devices).
The out-of-tree r8168-dkms package should never be necessary, r8169 is supposed to cover all recent RealTek cards - you basically just replace one set of bugs with another, at the price of having to deal with a …vendor driver.