On Thu, Jan 24, 2019 at 04:55:50PM -0600, John Page wrote: > This is my first attempt at a router. Liberally borrowing from tutorials > and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD > Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I > had previously been using an Asus RT-86U as both my router and wireless > access point. The apu4 can have wireless capability, but OpenBSD does > not support 802.11ac while the Asus does. So I decided to connect the > Asus to em3 of the apu4 so my wireless Windows 10 computers (both of > which have .ac) and Android phones could connect to the Asus instead of > the apu4 main router. Below is my stab at a network diagram (borrowed > and adapted) and the contents of my configuration files (again, borrowed > and adapted). > > My question is: OK, I understand that people more knowledgeable than I > am say that commercially available consumer-grade routers are not > secure. However, will I still have security risks associated with using > the Asus router when it is behind the OpenBSD/apu4 router? > > Also, any suggestions or comments would be appreciated.
WiFi chip firmware is notoriously buggy and exploitable. I chose a Google WiFi router (OnHub AC1900) specifically because it uses TPM-enforced secure boot (like a Chromebook) so rootkits can't survive a reboot--at least theoretically, but the track record is pretty good so far. And just as importantly it automatically updates itself. I don't trust Google not to spy on me, but I do trust them to earnestly keep any wardriving competition at bay by regularly fixing issues and pushing firmware updates. Secure boot and automatic updates means the WiFi security is *reliable* (regardless of whatever that security means), and one less thing to worry about. Keeping the router in bridge mode and running your own DHCP and DNS services, as you're doing, are obviously important. (Like you I have my WiFi router bridged to an APU.) I'm not so cynical to believe Google would implement DPI on their routers, but I find it hard to believe that they could resist, always and forever, capturing DNS metrics. If you're more paranoid than lazy you can setup IPSec tunnels from devices to the gateway. It's ridiculously easy on OpenBSD using isakmpd (L2TP/IPSec) or, especially, iked (IPSec/IKEv2 dynamic addressing). I've been using L2TP/IPSec tunnels when traveling for many years, but haven't bothered at home. IKEv2 dynamic address assignment does away with the need for L2TP (npppd(8)), but I haven't cared to spend the time to reconfigure my existing devices--desktop, personal/family laptops, work laptop, phone. Two caveats: 1) I don't know if it's possible to configure macOS or Windows (and almost certainly not Android or iPhone) to automatically establish a tunnel on your LAN but not elsewhere, so you'd have to remember to explicitly enable it regularly; and 2) while I think macOS (and iPhone?) finally got solid IKEv2 support in the past couple of years, I think Android might still only support IKEv1 and L2TP/IPSec VPNs. Rant: Android and Linux people seem to be going crazy about Wireguard, but Wireguard completely avoids the most difficult and complex aspect of running VPNs--key management and routing. Of *course* Wireguard is clean and simple; it avoids attempting to solve the dirty part, the most criticial part, the part that cries out for automation. What you see are people throwing together horrendous, ad hoc scripts for managing PKI and dynamic addressing and routing issues which hopelessly poor imitations of IKE if perhaps a step up from OpenVPN. Those hacks will only keep getting worse and more complex over time, recapitulating all the same mistakes, whereas IKE has reached the point where some of the complexity can be pared back. I won't be surprised when an IKE extension is published for establishing dynamic Wireguard flows. In the meantime there'll be (and already is!) a flood of proprietary, incompatible policy management daemons, just like with SSL VPNs. Next thing you know some big corporation will foist a TCP replacement upon everybody because TCP is too old and hoary, and who doesn't want to run an entire networking stack in each and every process that uses the network, completely divorced from the entire stack of existing network management (including non-invasive management) software and protocols. Also because of security, except let's gratuitously toss in an easily abused, totally insecure RTT feature to mitigate horrendous request latencies induced by the very same [ad] company complaining about performance.
