>you're much better off with something like an ER-X I pretty much recommend a plain jane router which can run DD-WRT for anyone. All this is clearly overkill, and more importantly useless for most people.
Another choice is getting a cheap NUC like x86 device and get AP-only devices for good coverage.
Be careful, this isn't true... most low end Intel chips (Celeron, Pentium, i3) don't support AES-NI. Starting with Skylake chips (2015/2016-era), the whole processor line supports AES-NI. See https://en.wikipedia.org/wiki/AES_instruction_set
I usually build the software from source so I don't know if every thing will work fine for you. Nevertheless here are the package names I remember from when I first set it up.
pdnsd - for DNS caching read the manual so you can write a good config, and don't forget to change the bind IP to an interface so that it is accessible to the local network
openvpn, easy-rsa - Initial setup[2] there is a bug which for which there is a temporary fix[3]. Might be fixed by now.
Port forwarding: I currently use iptables, but I've been trying to move to nftables, which I recommend. Here's how I do it for now (this must be done on the OpenVPN server):
tun0 is the openvpn interface
eno1 is the public ethernet interface of your VPN
Say the IP addr of openvpn CLIENT (router in this case) is 10.8.0.2 - eno1 port you want to forward to is 1234
say the client port (the router port to be forwarded) is 6789
#iptables -t nat -A PREROUTING -p tcp -i eno1 --dport 1234 -j DNAT --to-destination 10.8.0.2:6789
#iptables -A FORWARD -p tcp -d 10.8.0.2 --dport 6789 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
The above commands are not persistent so save them to /etc/iptables.conf
I always choose very conservative settings for firewall. Only a single port is forwarded to the VPN. Rest are closed, spoof open ports, and have a honeypot if you want.
There are many guides on iptables, but I would again recommend nftables. You're going to have to dig deep sometimes since it is still new.
If you have questions about anything, just google. Chances are, it has already been covered several times.
[1]: https://arstechnica.com/gadgets/2016/04/the-ars-guide-to-bui...
[2]: https://www.digitalocean.com/community/tutorials/how-to-set-...
What problem does this solve? Is it a bid to improve privacy?
This is especially useful when you have an application which doesn't cache DNS requests and issues a new one for every connection. Torrenting gets a big boost for example.
Privacy is just a side effect.
EDIT: Also, "Torrenting gets a big boost for example." sounds strange, don't trackers give out IP addresses? Why would BitTorrent be DNS bound?
I have it set up to be 1 day. Most websites have been setting up low TTLs like 1 hour or less because they don't want to take a chance in case of a problem, and DNS is cheap or free these days.
About your statement - 'don't trackers give out IP addresses?', what do you mean?
Often trackers are addressed by their domain (I've never actually seen a tracker without one). So each torrent has its own specific set of trackers. So all those trackers are frequently resolved and contacted for peer exchange.
So then the DNS curb would be looking up the hostnames of the trackers, which I'd guess would be under a dozen or so hosts (I don't know, I'm just guessing) per torrent. That seems unlikely to be a hot-spot to the degree that enforcing a long cache would provide a "big boost" to overall performance.
OpenDNS look up for Google just now took me 500ms, even without the VPN. I use tunnel mode for DNS on the NAS, which can easily double it.
1. Persistent DNS cache using pdnsd (even after reboot because it is on-disk) with a long minimum global TTL. You would imagine this would be a problem, but surprisingly I haven't had any. I've only had to get in once to correct something. You can manually purge a specific domain, and all of them if you think something is wrong.
2. Powerful enough for good OpenVPN settings. Automatically routes through a VPN, and can be disabled for a specific client if needed. The AES instructions (which are on any Intel chip after 2008) help out immensely compared to using just a generic router.
3. Smoother LAN transfers. A cheap gigabit PCIe card (Intel EXPI9402PT - on ebay for about $20) which takes away local transfer rate problems, especially if you have an NAS.
4. Use it as an NAS. It isn't a good idea to mix devices which need good security with non-critical systems, like NAS so be sure about your settings and know what you are doing.
Another cool thing is port forwarding to the remote VPN instance so you can login remotely and check out your network or access any files/media you have on your NAS.
There are more things people can do which give more control and/or better experience, like setting up rate limiting on clients, custom settings for clients with unknown MAC addresses, etc. Traffic shaping is a good one (prioritize specific type of connections over another - example VoIP > Netflix > torrent).
The extra power really opens up the possibilities of what a router can do.
If anyone has any questions, I'd be glad to help out.