Idiot's Guide to Configuring Wireguard - Client Tunnel

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2, 3  Next
Author Message
Hellakenut
DD-WRT Novice


Joined: 22 Mar 2019
Posts: 21
Location: Gamma Quadrant

PostPosted: Fri Apr 05, 2019 9:04    Post subject: Idiot's Guide to Configuring Wireguard - Client Tunnel Reply with quote
Welcome to my idiot’s guide to setting up a Wireguard client tunnel!

I wanted to make a beginner-friendly tutorial for setting up Wireguard on DD-WRT. Most of the information currently given on this site is for already experienced users who know how to navigate the DD-WRT GUI, use commands to alter startup parameters/firewall rules, and perform tasks in Telnet/SSH terminals. For people who are flashing DD-WRT for the first time, this is going to sound overwhelming and come off confusing to inexperienced eyes, so I wanted to make a palatable guide that would help new users configure a Wireguard tunnel/client for the first time. Doing so will allow you to route ALL traffic from your LAN devices through the Wireguard tunnel on your router.

Exclamation THE INFORMATION PROVIDED HERE IS EXPERIMENTAL Exclamation

Let me preface that Wireguard is still in beta as of writing this guide. Things I mention here can and/or will change in the future as Wireguard develops. I will try to keep this up to date if things change in the Wireguard GUI, but in off chance I go dark forever or have an affair with the OpenWRT community, a moderator can happily adapt this guide and repost it. Or it can fade into obscurity, idc, lol. This is the internet after all.

Also, this guide is going to be for a very basic setup. I unfortunately can’t help you if you are looking to do more than what I describe here. But if you are reading this and can give some more info on how to set up a more advanced task involving Wireguard, feel free to post your knowledge!

I must give credit to the following users for making this information available in a way I can digest:


audia3
liverpoolatnight
eibgrad



Without them I’d never have gotten this to work, so they deserve full credit for the majority of the information I provide in this tutorial! Very Happy

Also, the pictures I post are resized by the forum. So if you can't read anything, make sure to click the images to view the full size!

Table of Contents:

    ○ Wireguard Intro/Benchmark Comparisons
    ○ Wireguard Setup Tutorial
    ○ Optional Settings
    ○ Troubleshooting/Issues

- Wireguard Intro/Benchmark Comparisons

So... why Wireguard instead of OpenVPN?

The biggest struggle with running a VPN client on your router is the need for a powerful CPU to handle the necessary encryption processes. Unfortunately, OpenVPN is built to utilize only a single core, therefore it cannot take advantage of any additional power in your router. So unless you have a really high clock rate for a single core, you are going to see a serious bottleneck on your internet speeds when using OpenVPN on your router.

This is where Wireguard has turned heads. It DOES take advantage of all CPU cores and the overall footprint of the VPN is much more lean and efficient. With that in mind, how much of a speed improvement does Wireguard have over OpenVPN?

See these tests below. I compared the down/up speeds of my 100/100 fiber internet using my standard ISP connection, Wireguard, and OpenVPN. The results are pretty staggering:



My router is currently a Linksys EA6900, with an 800MHz dual-core processor. 800MHz for OpenVPN is, shall we say, not exactly optimal for running a VPN. However, Wireguard gives me nearly the full down/up speeds that my ISP provides, which is a pretty wild improvement.

Nevertheless, don’t take my results as an objective benchmark. Wireguard is still very young and not a finalized protocol, so there will be varied performance depending on your hardware, build, location, etc. I sadly can’t guarantee ANYTHING to you in terms of expectations and reliability.

But now that you have a picture of what Wireguard can bring to the table, let’s move on to the tutorial!

- Wireguard Setup Tutorial

To get started, you must have the following:

    • A VPN provider that supports the Wireguard protocol (e.g. Mullvad, IVPN, AzireVPN, etc.).
    • A router that is currently running a Brainslayer build w/ the Wireguard GUI. [1]
    • An SSH program to log into the router. I highly suggest PuTTY for this. PuTTY Download Page
    • Patience and a willingness to troubleshoot!

[1] If you are using a Kong build, Wireguard may or may not be natively supported in the GUI. If not, you must install it separately using the methods described here: https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1152435

Word of caution: As kooper2013 experienced in this thread, I do NOT recommend running the mentioned commands/scripts in this guide using the DD-WRT GUI commands box. Unexpected results or errors may occur, so make sure you execute them through a Linux/Putty terminal! Use the GUI commands box primarily to make changes to your startup, firewall, and custom script fields.

For this tutorial, I will be using Mullvad as my VPN provider to work off of. Please keep in mind that VPN providers may have their own tutorials for configuring Wireguard on custom router firmware (if so, try and reference their guides prior to reading this!). However, in my case, Mullvad only explains the process for OpenWRT, which does not translate clearly to DD-WRT. So for those that don’t have documentation specifically for DD-WRT, this guide should help push you in the right direction for getting a basic connection set up.

1. Enable Wireguard in DD-WRT

First off, we need to enable Wireguard in the GUI to get the ball rolling. To do so, log into your router and under the Setup tab, navigate to the Tunnels tab. You should see the following:



Select the “Enable” radio button and you should see some settings appear, one that’s a drop-down menu. Click the drop-down menu and select the option “Wireguard.” After that, hit the "Add Peer" button and you should now see the following items:



From here, you should see the text box titled “Local Public Key.” Hit “Generate Key” to create a custom public key that we’ll use with our VPN provider.

2-A. Use Local Public Key to get IP for Wireguard Tunnel

This is where PuTTY comes in. First, make sure SSH is enabled in DD-WRT by going to the Services tab. Scroll down until you see the section named “Secure Shell.” Make sure the option “SSHd” is set to enable (you may need to reboot your router for it to take effect). Once that’s done, launch PuTTY and select the radio button that says “SSH.” Enter your router’s address (e.g. 192.168.1.1) in the Host Name field and hit “Open.” You should see the terminal box below:



For the login, you will type “root” and press enter (this is the master username). The next output should ask for your password, which is the same password you set to log into your router. If you entered the information correctly, you should see the DD-WRT welcome screen below:



Congrats! You’re in. Now from here, we are going to fetch some information to plug into the Wireguard interface in DD-WRT. Note, this step may vary WIDELY depending on your VPN provider. For Mullvad, you are required to run this command to get an IP address to use with your router:

Code:
curl https://api.mullvad.net/wg/ -d account=YOURMULLVADACCOUNTNUMBER --data-urlencode pubkey=YOURPUBLICKEY


As the placeholders suggests, plug your Mullvad account number where it says “YOURMULLVADACCOUNTNUMBER” and the Local Public Key you generated back in the Wireguard GUI where it says “YOURPUBLICKEY” in the command.

FYI, in my case this code failed due to a (60) SSL certificate problem. If this happens to you, append your code to the following to skip SSL verification:

Code:
curl -k https://api.mullvad.net/wg/ -d account=YOURMULLVADACCOUNTNUMBER --data-urlencode pubkey=YOURPUBLICKEY


The “-k” is what bypasses the verification. You can also try “--insecure” as an alternative.

You should now receive an IP address from your VPN provider. The output will be something like this:



For the purpose of this tutorial, I used a random generated public key to produce an IP address. So we’ll be using 10.99.5.54/32,fc00:bbbb:bbbb:bb01::536/128 from here on out as a placeholder. Also, ignore the IPv6 portion of the address as we won’t be using it in this tutorial (just focus on 10.99.5.54/32).

This returned address is what we’ll use to put into the Wireguard GUI in DD-WRT. Head back to your browser and return to the Setup > Tunnels tab in DD-WRT. From here, we’ll insert the IP address we received from our VPN provider in the space below:



So we received the IP address, but what goes in the Subnet Mask field? As of writing this tutorial, the only provider-supported guides to setup Wireguard are for OpenWrt, not DD-WRT. Because of this, there are a fair amount of discrepancies between the two firmwares, one of which being the lack of needing to define a subnet mask in OpenWrt. DD-WRT, on the other hand, wants this information. For those who are unfamiliar with networking, the subnet can be calculated from this number:

10.99.5.54/32

The highlighted part tells us the subnet. This shorthand version is known as CIDR notation. Without going into the gory details on how it works, I’m providing a cheat sheet that you can reference to translate the notation. The IP you receive from your VPN may have a different CIDR number, so use this to determine your subnet mask:



2-B. Use Private Key to get IP for Wireguard Tunnel

*You can skip to step 3 if step 2-A worked for you*

If all else fails and you can't obtain an IP address using the methods described above, you can use your private key instead if your VPN provider allows you to generate a Wireguard config file from a preexisting private key. In Mullvad's case, we can. Unlike OpenWRT, DD-WRT does not display the private key in the GUI. In order to get it, open up an SSH terminal using the process described in step 2-A, and in the terminal type the following command:

Code:
wg showconf oet1


You should get an output like this:



The "PrivateKey" portion is what we want. Highlight the generated key and it will automatically be copied to your clipboard. Now navigate to your VPN provider's webpage that allows you to generate a Wireguard config file. For Mullvad, the page looks like this:



Make sure "Custom key pair" is selected and paste the private key you got from the terminal into the box that says "Enter private key..."

From here, refer to step 3 to determine your server information. Once you've selected the appropriate Wireguard server you want, download the file and open it. You should see something like this:



The line that says "Address = 10.99.5.54/32,fc00:bbbb:bbbb:bb01::536/128" is what we need for the IP address/Subnet Mask area in the Wireguard GUI (again, ignore the IPv6 portion). We will also be ignoring the DNS line in this config file. Once you have this, jump to the end of step 3 (where the picture of the config file is) and follow the remaining steps normally.

3. Get Wireguard Server Information

Next, you are going to need to get the information of the specific Wireguard server you are trying to connect to from your VPN provider. Note that these servers are separate from the OpenVPN ones, so make sure you go to your provider’s website and find a list that specifically labels the Wireguard ones.

This is where DD-WRT might make you take a detour. If you’re lucky, your VPN provider will show the IP address along with the domain name of the server you want to connect to. If that’s the case, great! Skip to the next step. But if you use Mullvad like I do, only the domain names are listed. DD-WRT doesn’t play nice with this because there is a character limit in the field we need to put this information, so only the plain IP address will work. In order to get this, we need to generate a config file from our VPN provider. Your VPN should provide a webpage where you can create a Wireguard config file for a specific operating system. Mullvad’s looks like this:



For the operating system, I just chose Linux and had it generate a new key pair (we won’t be using these keys). For the server, select the one you wanted to use and get the IP from. After that, hit Download and open the config file you get in Notepad or any other text editor. You should see something like this:



The [Peer] portion is what we need. The Endpoint is the IP address of the server you picked. Also take note of the port number, which is 51820. We now have all the information we need to finally get connected!

4. Plug All the Information in the Wireguard GUI

Back in the Wireguard GUI, put all your settings in as follows:



The MTU box will fill automatically. Once this is done, hit apply and Wireguard should now be configured correctly. Next, we need to make changes to the startup script, firewall, and add a custom script to get the tunnel working. Navigate to the Administration > Commands tab and paste the following into the Commands box: [2]

Code:
#!/bin/bash
while :
do
WGPROC=$(wg)
WGIF=$(ip route show gateway | grep -io oet1)
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
WANIF=$(/usr/sbin/nvram get wan_iface)
HOST=$(ip route | grep -E "($WGSERVER.*$WANGWY)")
until /usr/sbin/nvram get wanup | grep -q 1
do
echo "Waiting for WAN to initialize..."
sleep 10
done
if [ "$WGPROC" ]
then
echo "Wireguard is running. Checking routes..."
if [ ! "$WGIF" ] || [ ! "$HOST" ]
then
echo "Routes missing. Correcting..."
route add -host $WGSERVER gw $WANGWY dev $WANIF
route del default
route add default dev oet1
ip route flush cache
echo "Done"
else
echo "Routes are correct"
fi
else
echo "Wireguard is not running"
fi
sleep 60
done


Note the line that says WANIF=$(/usr/sbin/nvram get wan_iface) in the script. Due to a varying degree of setups that people may have (e.g. iphone/android tethering, bridging, etc.) you may need to configure this variable manually if you are running a setup that doesn't automatically use the default WAN interface on your router. In the case of phone tethering, your WAN interface is the device you set to receive internet from. So this could be iph0, usb0, or whatever the necessary naming scheme for your device was required. If your WAN interface is NOT the default assigned in the nvram, then set your WANIF variable like such (keep the quotations around the interface name you have):

Code:
WANIF="your interface name here"


Again, this interface can be iph0, usb0, etc. For a specific startup script altered to detect iphone tethering, see audia3's post here.

Once you've entered the script, scroll to the bottom of the page and hit “Save Custom Script.” When the page reloads, paste sh /tmp/custom.sh in the Commands box and hit "Save Startup" at the bottom of the page. This will execute the custom script on startup and route your LAN devices to go through the Wireguard tunnel (oet1) once your router boots up. Finally, the tunnel needs to get passed the firewall. Paste this into the Commands box:

Code:
iptables -t nat -I POSTROUTING -o oet1 -j MASQUERADE


Hit “Save Firewall” to add the rule.

Reboot the router and, if you did everything correctly, you should be connected through Wireguard! Check your IP online to make sure it’s displaying the endpoint address you entered. If you don't have a connection, remove the startup entry for the custom script, reboot the router, and run the custom script manually in a terminal session to see if any errors come up. The command to execute the script is the same as the startup command, so paste sh /tmp/custom.sh and hit enter to run it. To stop the script at any time, hit Ctrl+C.

- Optional Settings

DNS Leaks:

You can also set your router’s DNS to that of your VPN’s if you are worried about DNS leaks. I’d at least recommend setting it to something that isn’t the router’s default (e.g. Comodo, Cloudflare, OpenDNS, etc.). You can easily find these online. Put the DNS server address under Setup > Basic Setup in the box that’s titled “Static DNS 1.” Preferably, fill all 3 Static DNS fields with alternate addresses.

Network Killswitch:

To add a kill switch in case you lose connection over your VPN, add the following commands to your firewall in Administration > Commands:

Code:
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -m state --state NEW -j REJECT --reject-with tcp-reset


With this, if the Wireguard server you are using goes down, or if your Wireguard interface gets disabled, your traffic will be blocked from accessing the internet and potentially leaking information.

- Troubleshooting/Issues

With anything that’s new, this setup is not without some problems. For one, if you make any general changes to your DD-WRT settings (e.g. enable something in Services), your routing table gets reset and you have to configure it again (this is what the looping custom script helps correct when it's run on startup). The Wireguard feature in DD-WRT should be able to account for this problem on its own, but sadly it does not at this point in time. Hence, the custom script provided runs quietly in the background on startup to make sure the routes are correct should something gets altered. Since it is an infinite looping script, this avoids relying on the cron service which, in my experience, did not run reliably upon a router reboot. You also save nvram space by not enabling the cron service.

If you find that Wireguard isn't connecting upon router reboot, remove the custom script line from startup, reboot again, log into the router through an SSH terminal, and run sh /tmp/custom.sh to view the output and determine where the script is getting hung up.

[2] ADVANCED DD-WRT USERS: PLEASE inform me of any better ways to go about doing this. I’ve only been using DD-WRT for a couple months, so if there’s a simpler solution out there to accomplish this then I’d be happy to amend it into the guide.

Thanks for sticking through all the way to the end. Hopefully your setup is working. If you have any corrections and/or better suggestions to include in this guide, please let me know and I’ll make the necessary changes as soon as possible. Thank you!


Last edited by Hellakenut on Tue Sep 10, 2019 0:09; edited 9 times in total
Sponsor
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sun Apr 07, 2019 0:57    Post subject: Reply with quote
First off, thanks for your efforts here. I know it can seem a thankless task, esp. when there's not much response. But it's going to take some time before ppl jump on-board a new VPN. As I've mentioned in other Wireguard threads, imo, this thing still remains unvetted and unproven. That just takes time. So everyone should be aware that this is a "use at your own risk" type of VPN for the moment.

Several points, in no particular order.

I have a rule of thumb that whenever something needs to be invoked every five minutes or less, it's usually better to have the script run in a continuous loop, sleeping at the end of that loop for say 60 secs, then continuing from the top. The reason? The startup costs associated w/ any process running from the scheduler are substantial when compared to just putting the script to sleep for awhile. Esp. when 99% of the time it's going to do nothing. And of course, you avoid any cron issues/idiosyncrasies as well.

Also, whenever you change the routing table, you need to clear the routing table cache, or there's a chance the change won't be recognized.

Code:
ip route flush cache


I'm also not a fan of constantly deleting the default route through each pass only to replace it (most of the time) w/ the same route. I can see that perhaps causing issues at times. The better option is to OVERRIDE the default route rather than replace it. And perhaps checking whether the overrides are there before deciding to rebuild the routing table. I'll try to come up w/ a replacement script and post it back here.

Frankly, I'm a bit surprised this loss of the routing is an issue. Might be better addressed by creating a wanup script, which is triggered each time the WAN is reinitialized (I'm assuming, of course, that whatever is messing w/ the routing tables is also reinitializing the WAN, but I'd have to check to be sure).

Whenever you deal w/ an VPN server YOU don't control (i.e., a commercial VPN provider), I recommend you take a defensive posture in your firewall rules and actively prevent anyone on the VPN server side from initiating connections into your network. I know, for example, this is an issue w/ the OpenVPN client GUI, as described in the following thread.

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=307445

You'll see some rules in that opening post that do just that. A comparable set of rules for Wireguard would be identical, except for changing the network interface name.

Code:
# allow only outbound connections to the VPN (no inbound)
iptables -I INPUT -i oet1 -m state --state NEW -j DROP
iptables -I FORWARD -i oet1 -m state --state NEW -j DROP
iptables -t nat -I POSTROUTING -o oet1 -j MASQUERADE


Since I'm not running Wireguard on dd-wrt at the moment, I don't know if this is really necessary. Perhaps this has already been done in the GUI. But given my experience w/ OpenVPN, I'm not willing to assume these protections have been added. It's just not a good idea to assume the VPN provider has firewall'd their end of the tunnel, or risk some rogue element on their own network from attempting to access your own network.

Of course, if the tunnel is intended to be bidirectional (aka, site-to-site), and you obviously have control over the OpenVPN server side, you don't need ANY of these rules. You typically want each side to be able to initiate connections, and can rely on static routes rather than NAT for getting communications working across the tunnel in either direction.

IOW, for the purposes of this guide, it assumes a unidirectional tunnel (typical for a commercial Wireguard provider). For a bidirectional tunnel, there would be some changes required, mostly involving the firewall rules.

Btw, you can't always assume the WAN is vlan2. Older routers used vlan1 in many instances, and even others may be using PPPoE (e.g., ppp0). Using a hardcoded vlan2 will work *most* of the time, but sooner or later someone will have vlan1, ppp0, whatever, and it won't work.

JMTC
audia3
DD-WRT Novice


Joined: 10 Mar 2018
Posts: 21

PostPosted: Sun Apr 07, 2019 11:36    Post subject: Reply with quote
This is an excellent thread -- thanks Hellakenut and eibgrad!

For what it's worth, I was successful in getting WireGuard to run through my router while it is USB tethered to my iPhone. The key was to modify the startup script. I bumped the delay to 60 seconds because the iPhone tethering connection takes longer to come up and I changed 'vlan2' to 'iph0'.

Quote:

sleep 60
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
route add -host $WGSERVER gw $WANGWY dev iph0
route del default
route add default dev oet1
Hellakenut
DD-WRT Novice


Joined: 22 Mar 2019
Posts: 21
Location: Gamma Quadrant

PostPosted: Sun Apr 07, 2019 22:01    Post subject: Reply with quote
Thank you so much for your feedback, guys! And good to know you got the tethering setup figured out, audia3! Cool

@eibgrad: I'm very grateful for your input here. I kept running into older posts from you when researching info for this guide, so you've been a big help for me.

Looking forward to your script to help mitigate the routing issue!
coprophile
DD-WRT Novice


Joined: 10 Apr 2019
Posts: 1

PostPosted: Wed Apr 10, 2019 7:15    Post subject: Reply with quote
Thank you for taking the time to write this guide. Would it be possible to exclude some of my devices from the tunnel?
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed Apr 10, 2019 17:57    Post subject: Reply with quote
I was browsing the Wireguard developer's website and came across this interesting blurb.

https://www.wireguard.com/#conceptual-overview

A combination of extremely high-speed cryptographic primitives and the fact that WireGuard lives inside the Linux kernel means that secure networking can be very high-speed. It is suitable for both small embedded devices like smartphones and fully loaded backbone routers.

As I've been saying for some time, I believe the primary reason that *all* others VPN (PPTP, OpenVPN, etc.) on dd-wrt and other third party firmware perform so poorly is the fact that these VPNs typically run in user space, NOT the kernel. And that's a serious problem when it comes to constructing the tunnel. For every packet, the router has to make ring changes from user space to the kernel space and back again. And these consumer based routers just don't have the horsepower.

What the Wireguard developer did is really no different than what Microsoft did w/ Windows 3.x. The computers of that time were so underpowered, that they decided to put the GDI (graphics) routines in the kernel. If they placed those routines in user space, the drawing routines would have been so slow that users would have rightly complained. But while placing the GDI in the kernel helped, it made the system more vulnerable to attack, as we learned years later when the internet came along. Of course, at the time of that decision, that wasn't a consideration.

That's why no matter what you do to change your OpenVPN configuration, it just doesn't help. Whatever differences the choice of encryption make, they are relatively minor compared to these ring changes in terms of their impact. Just create a ptp (point to point) tunnel w/ static key (as I did many months ago), disable encryption, and you'll find that you get the same crappy results.

Of course, w/ Wireguard in the kernel, you have the *potential* for serious vulnerabilities, ones that *might* even make remote code execution possible. That's the tradeoff you make for performance, and why eventually this VPN needs to be heavenly scrutinized. And why you need to stay on top of any discovered vulnerabilities.

As far as OpenVPN, this is why I tell ppl all the time, if you're really need top performance, then unless you have a *very* powerful router that can handle the rings change efficiently, run it *off* the router! Even an old crappy PC from 10 years ago will vastly outperform the router. You're simply wasting your time trying to fix the performance problems on the router as long as OpenVPN remains in user space.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 4199
Location: Netherlands

PostPosted: Wed Apr 10, 2019 18:06    Post subject: Reply with quote
@eibgrad thanks for your insight, really interesting.

I stick to open VPN for the time being Smile

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed Apr 10, 2019 18:19    Post subject: Reply with quote
coprophile wrote:
Thank you for taking the time to write this guide. Would it be possible to exclude some of my devices from the tunnel?


You'd have to implement PBR (policy based routing). And unless BS adds that to the GUI, you'll need to implement it yourself. Fortunately, there really isn't much difference from VPN to VPN in how you implement PBR, esp. if you use PBR to direct source IPs *away* from the VPN.

https://wiki.dd-wrt.com/wiki/index.php/Policy_Based_Routing

So if we assume by default that everything is routed over the Wireguard VPN, it's simply a matter of copying the main/default routing table to an alternate routing table, adding the ip rules that specify which source IPs use that table, and executing it from probably the startup script. Or at least doing it before Wireguard changes the routing tables.

Code:
#!/bin/sh
TID="200"

ip route show | while read route; do
    ip route add $route table $TID
done

ip route flush cache

ip rule add from 192.168.1.7 table $TID
ip rule add from 192.168.1.100 table $TID
ip rule add from 192.168.1.113 table $TID
Hellakenut
DD-WRT Novice


Joined: 22 Mar 2019
Posts: 21
Location: Gamma Quadrant

PostPosted: Thu Apr 11, 2019 6:20    Post subject: Reply with quote
eibgrad wrote:
As far as OpenVPN, this is why I tell ppl all the time, if you're really need top performance, then unless you have a *very* powerful router that can handle the rings change efficiently, run it *off* the router! Even an old crappy PC from 10 years ago will vastly outperform the router. You're simply wasting your time trying to fix the performance problems on the router as long as OpenVPN remains in user space.


I debated doing this before ordering a newer router model (picked up a WRT3200 to play with). But laziness took hold and I wanted the task to be as "all in one" as possible, even if that means sacrificing VPN performance. I honestly wasn't expecting to get Wireguard to work on my EA6900 in the first place because the point of buying a new router was to improve OpenVPN's performance.

Needless to say, having the extra power from the WRT3200 will be useful for me to lean on if I ever need to switch back to using OpenVPN. I don't run a small business or have anything that needs crucial network protection, so I'm fine with being a test dummy for WG.

EDIT: Added additional info in the guide for confirming correct WAN interface in startup script. Thanks again, eibgrad!
Hellakenut
DD-WRT Novice


Joined: 22 Mar 2019
Posts: 21
Location: Gamma Quadrant

PostPosted: Fri May 03, 2019 10:50    Post subject: Reply with quote
An update on my Wireguard setup. Eibgrad mentioned making a loop for the route correction script, and as an attempt to dip my own toes in this territory, I have come up with an improved script that does not rely on a cron job or requires plugging in your WAN interface (this grabs that info automatically):

Code:
#!/bin/bash
while :
do
WGPROC=$(wg)
WGIF=$(ip route show gateway | grep -io oet1)
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
WANIF=$(/usr/sbin/nvram get wan_iface)
HOST=$(ip route | grep -E "($WGSERVER.*$WANGWY)")
until /usr/sbin/nvram get wanup | grep -q 1
do
echo "Waiting for WAN to initialize..."
sleep 10
done
if [ "$WGPROC" ]
then
echo "Wireguard is running. Checking routes..."
if [ ! "$WGIF" ] || [ ! "$HOST" ]
then
echo "Routes missing. Correcting..."
route add -host $WGSERVER gw $WANGWY dev $WANIF
route del default
route add default dev oet1
ip route flush cache
echo "Done"
else
echo "Routes are correct"
fi
else
echo "Wireguard is not running"
fi
sleep 60
done


This script checks if the WAN is up, and once it is, the necessary route checks/changes will be performed. I added this because I noticed the routes would be prematurely changed if Wireguard was running before the WAN came up (which is excessive because the routes automatically change when the WAN comes up, so it would end up changing it twice). So this script now waits for a WAN connection before changing/checking the routes. After running this for 10+ days now, the script has not duplicated itself, crashed, failed, or done anything to negatively effect general router performance when enabling/disabling Wireguard or making changes to settings. I call the script in the Startup section, so this eliminates the need for the startup commands mentioned in my guide. I can confirm that this script works on both my Linksys EA6900 and Linksys WRT3200.

Please try out the script and help confirm it's working or not. Thanks you guys!
audia3
DD-WRT Novice


Joined: 10 Mar 2018
Posts: 21

PostPosted: Sat May 04, 2019 20:14    Post subject: Reply with quote
Thanks for the script, Hellakenut! It's working for me after one tweak that is peculiar to my setup. I use my Asus RT-N66U as an iPhone USB tethered router. The first time I started with the new script, I had no internet. I discovered that the $WANIF variable was returning 'vlan2' instead of 'iph0', which is what I needed. When I hardcoded $WANIF to 'iph0', it worked! I need to figure out a way to get the script to determine if I'm tethering.
kooper2013
DD-WRT User


Joined: 10 Jan 2013
Posts: 60
Location: DE

PostPosted: Sun May 05, 2019 14:52    Post subject: Reply with quote
Hellakenut wrote:

...

Code:

#!/bin/bash
while :
do
WGPROC=$(wg)
WGIF=$(ip route show gateway | grep -io oet1)
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
WANIF=$(/usr/sbin/nvram get wan_iface)
HOST=$(ip route | grep -E "($WGSERVER.*$WANGWY)")
until /usr/sbin/nvram get wanup | grep -q 1
do
echo "Waiting for WAN to initialize..."
sleep 10
done
if [ "$WGPROC" ]
then
echo "Wireguard is running. Checking routes..."
if [ ! "$WGIF" ] || [ ! "$HOST" ]
then
echo "Routes missing. Correcting..."
route add -host $WGSERVER gw $WANGWY dev $WANIF
route del default
route add default dev oet1
ip route flush cache
echo "Done"
else
echo "Routes are correct"
fi
else
echo "Wireguard is not running"
fi
sleep 60
done


Please try out the script and help confirm it's working or not. Thanks you guys!


I'm getting always
sh: eval: line 6: syntax error: unexpected "(" (expecting "do")
when I try to run your script. What's the problem? All () seem to be correct...

~~

I'm trying to get wireguard as client running since days (Mullvad, Asus AC87U, bs r39654 currently). I know all this is kind of beta, but I always end up seeing my DSL-providers IP, never Mullvad's. I tried a lot of permutations, of various firewall-seetings, start/custom scripts, with and without.

The pain starts with syslog: Even if the 'Peer Public key' is forcedly wrong, I get
Jan 1 00:00:17 main kern.info kernel: wireguard: WireGuard 0.0.20190406 loaded. See www.wireguard.com for information.
Jan 1 00:00:17 main kern.info kernel: wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved.
Jan 1 00:00:17 main kern.info kernel: wireguard: packed headroom 128, message minimum length 32
Jan 1 00:00:17 main user.info root: Enable WireGuard interface oet1 on port 51820
Jan 1 00:00:18 main user.info root: Establish WireGuard tunnel with peer endpoint 31.7.59.xxx:51820
Jan 1 00:00:18 main kern.info kernel: device oet1 entered promiscuous mode

~~
Also,
ip route get 8.8.8.8
will only show
8.8.8.8 via 192.168.2.1 dev br0 src 192.168.2.100
which seems to be wrong, as it should state vlan2 or eth... (.1 is my DSL modem, .100 is the DD-WRT AP with wireguard).

What could possible be wrong? Something left over from OpenVPN settings? I really don't get it. And I don't like to set up my router from scratch.

All this is a big PITA, far from the 'easiest tunnel ever'...

_________________
3xBuffalo WLI-H4-D1300
1xBuffalo WZR-D1800H
1xBuffalo WHR-HP-G300N
1xBuffalo WHR-1166D (stock f/w)
1xASUS RT-AC87U
1xTP710
MesMurized
DD-WRT Novice


Joined: 08 Aug 2017
Posts: 9

PostPosted: Tue May 07, 2019 22:21    Post subject: Success with NordVPN - wireguard beta Reply with quote
Success with NordVPN on Linksys WRT3X Firmware: DD-WRT v3.0-r39296 std (03/27/19)

Thanks @Hellakenut for the extensive writeup and @eibgrad for additional information.....

Using your writeup, I was able setup NordVPN wg with the following changes:

Since wg is in early beta, I only had an Android config file to go by. Configuration is almost identical to @Hellakenut except for interface public/private keys.

I needed both keys, but only had the private and the GUI only produces a random public. So, I used wg pubkey < PrivateKey > Publickey, then manually set both with nvram set oet1_public=" <PublicKey> " and nvram set oet1_private=" <PrivateKey> " (no spaces), then nvram commit. Also, my WAN interface is eth0, so routes needed adjusting as well

NordVPN has only two wg beta servers at this time and they are several thousand miles away. Speeds were mediocre to slow.
MesMurized
DD-WRT Novice


Joined: 08 Aug 2017
Posts: 9

PostPosted: Tue May 07, 2019 22:35    Post subject: Reply with quote
kooper2013 wrote:

[code]
#!/bin/bash
while :
do
WGPROC=$(wg)
WGIF=$(ip route show gateway | grep -io oet1)
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
WANIF=$(/usr/sbin/nvram get wan_iface)
HOST=$(ip route | grep -E "($WGSERVER.*$WANGWY)")

...
Try changing while : to while true and adding a space between $( and ), ie:
WGIF=$( ip route show gateway | grep -io oet1 ).

Had similar problems and worked for me. Pretty sure it's caused by different shells.
audia3
DD-WRT Novice


Joined: 10 Mar 2018
Posts: 21

PostPosted: Wed May 08, 2019 21:18    Post subject: Reply with quote
Here's an updated version of the script that checks for iPhone tethering. From what I can tell, the wan_proto variable is 'iphone' when tethering and 'dhcp' when connected to ethernet for the WAN.

#!/bin/bash
while :
do
WGPROC=$(wg)
WGIF=$(ip route show gateway | grep -io oet1)
WGSERVER=$(/usr/sbin/nvram get oet1_rem0)
WANGWY=$(/usr/sbin/nvram get wan_gateway)
WANP=$(/usr/sbin/nvram get wan_proto)
if [ $WANP='iphone' ]
then
WANIF='iph0'
else
WANIF=$(/usr/sbin/nvram get wan_iface)
fi
HOST=$(ip route | grep -E "($WGSERVER.*$WANGWY)")
until /usr/sbin/nvram get wanup | grep -q 1
do
echo "Waiting for WAN to initialize..."
sleep 10
done
if [ "$WGPROC" ]
then
echo "Wireguard is running. Checking routes..."
if [ ! "$WGIF" ] || [ ! "$HOST" ]
then
echo "Routes missing. Correcting..."
route add -host $WGSERVER gw $WANGWY dev $WANIF
route del default
route add default dev oet1
ip route flush cache
echo "Done"
else
echo "Routes are correct"
fi
else
echo "Wireguard is not running"
fi
sleep 60
done
Goto page 1, 2, 3  Next Display posts from previous:    Page 1 of 3
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum