root

I've actully did more test this morning and i'm getting full 100mbs over vpn (with the isolated cpu).  There is probably less traffic on a sunday morning.  Also i think i might be connected to a better server.
when you run your speed test make sure it uses a different core than the openvpn:
 
taskset -c 0 python3 speedtest.py  
root@renegade:/mnt/data# taskset -c 0 python3 speedtest.py Retrieving speedtest.net configuration... Testing from Amanah Tech (104.254.93.181)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Ookla (Toronto, ON) [2.60 km]: 62.424 ms Testing download speed................................................................................ Download: 95.08 Mbit/s Testing upload speed...................................................................................................... Upload: 10.55 Mbit/s  
 
Another option to prevent anything from being scheduled on your openvpn core is to modify the /boot/boot.cmd and add isolcpus=2 to the bootargs (you will still need the CPUAffinity setting in the systemd openvpn.services file to run it on core 2):
 
setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs} isolcpus=2" Then run:
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot.
 
 
Let us know what speeds you get from wireguard, i wish my  provider supported it, but you shouldn't have to do any of this crap to get full speed with wireguard.

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Until getting a second adapter, I set off to see if there's anything else that can be done with my current hardware. And... there is. 
I managed to make the TinkerBoard my VPN router using Wireguard. It would be similar with OpenVPN, but (see figures above) speeds are not that exciting.
 
If anyone else is interested, here are the steps. I assume you are using a "standard" setup with your end equipment (laptops, PCs, TVs etc) connected to a router (I have a Netgear R7000), which in turn is connected to a cable modem / fiber modem / any other sort of uplink.
What you need: TinkerBoard (TB for short) running Armbian, power supply, a network cable, case (optional, using the RPI 3 standard one), a WireGuard or OpenVPN connection to a remote endpoint.
 
1. Install Armbian on the TB.
2. Connect your TB to the router using a wired connection. You will get an IP address, say 192.168.1.5. The router is 192.168.1.1 and your PC is 192.168.1.10.
3. Perform a full update (apt update && apt dist-upgrade) and reboot (you will likely need to power cycle the box, mine doesn't reboot properly).
--> Note: I believe the OpenVPN package in the Armbian is a bit old (I think I saw 2.3.10, current is 2.4); this may give you trouble with some options.
4. Set up your WireGuard or OpenVPN connection on the TB. Note Jason's hint above about removing the ipv6 route. Install the iptables package (apt-get install iptables).
5. Bring up your WireGuard or OpenVPN tunnel. You will get a new interface (called as you wish - we'll use wg0 for the Wireguard one and tun0 for the OpenVPN).
So far so good, all standard steps. Now comes the slightly trickier part.
6. On your router, in the DHCP options (this typically sits in the LAN chapter, YMMV), set the default gateway (the one which gets sent out to clients) to 192.168.1.5 (the IP of the TB).
7. On the TB, issue the following commands to enable packet forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/route add default gw 192.168.1.1 dev eth0 /sbin/iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT /sbin/iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE Above - eth0 is the router's interface which carries the IP address 192.168.1.1. wg0 is the Wireguard interface on the TB (tun0 would be VPN one).
If you want to make the changes permanent, edit /etc/sysctl.conf for ip_forward and add the iptables and route lines somewhere (I'm lazy, so I've put them in rc.local)
 
8. Reconnect your computer to the LAN (replug the cable, ipconfig /release and /renew and so on). Your gateway should now be 192.168.1.5 (instead of the old 192.168.1.1
9. Try pinging a remote host, should work. Try a traceroute, the first hop should be 192.168.1.5, the second 192.168.1.1, the third your Wireguard/OpenVPN remote end. 
10. If you have any special routes declared on the old router, you will need to carry them over to the Tinkerboard. For instance, add the necessary commands to rc.local (yes, lazy).
11. If everything works, don't forget to make your tunnel start automatically, prior to any iptables / route invocations. OpenVPN starts as a service, for Wireguard I've set a manual call in (no surprise...) rc.local.
 
The result: I'm maxing out my Internet connection (200+ Mbps down) while using Wireguard. In order to do that with OpenVPN, I would have needed an i3 (at least, if not an i5) processor.  I'm happy.
Thanks to the Armbian team, to Jason for Wireguard, to Mullvad.net for providing the testing infrastructure.

Hi @root,
 
Thanks for your debugging gzip and testing that the workaround was successful.
 
It looks like the core of the issue is that the Armbian kernel you're using doesn't enable CONFIG_IPV6_MULTIPLE_TABLE (even though it does enable CONFIG_IP_MULTIPLE_TABLES, the IPv4 equivalent). While you don't use IPv6, so this doesn't really matter for you, others do and the ability to do policy routing with multiple routing tables is pretty much an "expected feature" of Linux these days. So it's a bit odd that it's there for v4 but not for v6. I'm guessing this is just a simple error in the default kernel config, so I've submitted this pull request for fixing it: https://github.com/armbian/build/pull/727
 
In any case, from your perspective, I think the workaround suggestion of my first reply is the correct way. Since you're not using v6, and not specifying a v6 interface address, it doesn't make much sense to have the v6 default gateway (::/0) in AllowedIPs or in your routes. So, with the change you made, things are now coherent and fine.
 
We have, in the process though, unearthed a potential problem for other Armbianers down the road, so thanks for the detailed report.
 
Jason

Hey there,
 
WireGuard author here. Sorry to hear you're having problems. This certainly seems like strange behavior. Could you send me the output of:
cat /proc/version cat /lib/modules/$(uname -r)/build/.config || zcat /proc/config.gz || cat /boot/config-$(uname -r) ip -d addr ip -d route sysctl net Then I can get to the core of the issue.
 
However, in looking for a workaround, you might try mitigating this issue by removing "::/0" from the AllowedIPs= line of your config file, so that it only reads "AllowedIPs=0.0.0.0/0". I'd be interested to learn whether this "fixes" the problem.
 
Also, the best place to get help in real time is on the WireGuard IRC channel -- it's #wireguard on Freenode.
 
-Jason

Yep, that's fine for me. I'm a bit dated, hence shying away from all this ipv6 thing.