DDWRT WireGuard Client Setup Guide v37

DDWRT WireGuard Client setup guide
Latest version see: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624
Introduction
This guide covers the setup of a WireGuard client to a (commercial) WireGuard VPN Provider/Server.
Set up of WireGuard as a server(i.e. for connecting to your home from outside) is covered here.
WireGuard is an open-source VPN solution written in C by Jason Donenfeld and others, aiming to fix
many of the problems that have plagued other modern server-to-server VPN offerings like
IPSec/IKEv2, OpenVPN, or L2TP.
It can be seen as a replacement for OpenVPN although it does not have the versatility, possibilities
and track record of OpenVPN yet.
However, it has two advantages over OpenVPN, it is much faster especially on lower-spec hardware
such as Soho routers (my own R7800 goes from 85 Mb/s on OpenVPN to 270 Mb/s with WireGuard)
and is easy to setup if you know how, the guides will help you with that.
To work with this guide DDWRT build 52242 or higher is mandatory.

See Forum guidelines where to download firmware.
WireGuard is usually available on routers with 8 MB Flash RAM or more (there are a few exceptions)
and using at least Kernel 3.10 (so not on K2.6 builds).
General Remarks
The most important parts of Wireguard are the public/private keys and the Allowed IP.
The public key is distributed to the peers.
The Allowed IP serves two roles, the first is that the allowed IP is used to know which of the peers
public keys (if there is more than one peer) should be used to encrypt the packets.
The second one is security, if Wireguard detects a source IP which is not in the Allowed IP's the
packets are discarded.
The keys are 32 bytes long and can be easily represented in Base64 encoding in 44 characters the last
character is always an =.
DDWRT Wireguard client setup guide by egc, last modified: 9-Sep-23 page 1
INDEX
Introduction............................................................................................................................................. 1
General Remarks ..................................................................................................................................... 1
Providers.................................................................................................................................................. 3
Step 1 Obtaining a setup (conf) file ..................................................................................................... 4
Step 2 Setup file................................................................................................................................... 4
Step 3 setup the WireGuard Tunnel manually .................................................................................... 5
Step 4 add Tunnel settings .................................................................................................................. 7
Step 5 setting up the Peer ................................................................................................................... 8
Step 6 checking connection ............................................................................................................... 10
DNS settings .......................................................................................................................................... 12
DNS servers via tunnel....................................................................................................................... 12
Options settings..................................................................................................................................... 12
Firewall Inbound: Enabled (checked) ................................................................................................ 12
Kill Switch: Enabled (checked) ........................................................................................................... 12
Route-up and Route-down scripts .................................................................................................... 13
Allow Clients WAN Access ................................................................................................................. 13
Bypass LAN Same-Origin Policy ......................................................................................................... 14
Policy Based Routing ......................................................................................................................... 14
Source Based routing ........................................................................................................................ 14
Route all sources via VPN .............................................................................................................. 14
Route Selected sources via VPN: ................................................................................................... 14
Routed selected sources via the WAN .......................................................................................... 15
Destination Based Routing ................................................................................................................ 15
Route selected destinations via WAN ........................................................................................... 16
Route selected destinations via the VPN ...................................................................................... 16
Split DNS ............................................................................................................................................ 16
Source routing ............................................................................................................................... 17
Destination routing........................................................................................................................ 17
Failover member/Watchdog ............................................................................................................. 17
Switching between tunnels ................................................................................................................... 18
Basic IPv6 support ................................................................................................................................. 18
Troubleshooting .................................................................................................................................... 19
Deleting INVALID rules ...................................................................................................................... 19
Miscellaneous .................................................................................................................................... 19
Port forwarding via WireGuard (oet) interface ................................................................................. 20
Running concurrent with OpenVPN Client. ....................................................................................... 20
References ......................................................................................................................................... 21
Custom PBR script ................................................................................................................................. 21
Specific Provider Settings ...................................................................................................................... 21
TorGuard ........................................................................................................................................... 21
Mullvad .............................................................................................................................................. 21
Private Internet Access (PIA) ............................................................................................................. 22
Cloudfare Warp ................................................................................................................................. 22
NordVPN ............................................................................................................................................ 23
IVPN ................................................................................................................................................... 23
Oracle Cloud setup ............................................................................................................................ 23
Proton ................................................................................................................................................ 23
Providers
Almost all major VPN providers now offer WireGuard, some only let you use an app and hence do not
support setting up WireGuard on a router.
The VPN providers who do support setting up WireGuard on a router almost always do it by
providing a setup or conf file with keys, and addresses.
How to obtain those setup files depends on your provider so look at their support site or ask the
help desk of your provider.
Some providers let you upload your own local Public Key, an example is Mullvad, for a description
how that works see @Hellakenuts excellent guide.
Take note: you do not need to use a script any more just Enable NAT out via tunnel and as Allowed
IP's use: 0.0.0.0/1,128.0.0.0/1 and Enable Route Allowed IP's
This guide focuses on setting up for VPN providers which hand out a setup file using a local Private
Key.
These include, KeepSolid, VPN Unlimited, Azire and many more.
As an example I use KeepSolid (very cheap but you get what you pay for).
Step 1 Obtaining a setup (conf) file
This is different per provider for this provider I log into the user account (called user office) choose
VPN/Manual Configurations/Create Device/Choose WireGuard/Choose server
Then click Generate and download the setup file.

For other providers let me know the procedures for obtaining a setup file so that I can include them.
Step 2 Setup file
When the setup file is opened with notepad or your favourite editor, it looks like this (note there are
differences between providers, e.g. not all use a PresharedKey):
[Interface]
PrivateKey = 2EzUYqrpv/FP6f31h7Zsi2wii3YdiwlGtFSGJmW+a2c=
ListenPort = 51820
Address = 10.100.0.139/32
DNS = 10.100.0.1
[Peer]
PublicKey = gAyw0BluPeJFrKNSuieYdTQXGttf2rNVU1Rg3VrP5Sk=
PresharedKey = Ag+IEIT5CgVwpwDppzfjbxtnyaqVWJn35z7+gjaT6co=
AllowedIPs = 0.0.0.0/0
Endpoint = 77.81.98.70:51820
PersistentKeepalive = 25
Basically this is all we need to setup the DDWRT router as a WireGuard client.
Builds after build 47285 have an import utility which will import this config file and setup the tunnel,
so that you can setup a tunnel with a few mouse clicks.
Basically head over to the Setup/Tunnels page and hit the Import Config button.
Choose the config file and let the magic happen.
After importing check your settings make sure KeepAlive is set to 20 or 25, there are some providers
which do not add the KeepAlive setting to their configs.
When you are done click Apply Settings.

(Sometimes you have to refresh your browser (CTRL+F5) to see all fields i.e. the Local Public Key)
To setup manually proceed with step 3.
Step 3 setup the WireGuard Tunnel manually

Open the routers GUI in your favourite web browser and go to Setup>Basic Setup>Tunnels and click
Add Tunnel:
Click Enable and choose Protocol type: Wireguard:
Step 4 add Tunnel settings
From the setup file fill in the right settings:

1. CVE 2019-14899 Mitigation :Enable (for site-to-site setup Disable)
2. Tunnel Obfuscation: Disable, this is to obfuscate traffic and can only be used if the server side
also has obfuscation.
3. NAT via Tunnel: Enable
4. Local Port = Listen Port from setup file in this case it is the standard port but different
providers will use different ports: 51820
Although the Listen Port can be chosen freely as the client will advertise the Listen Port to
the server this does not always work. Some providers have a suboptimal implementation and
insist on using the same Listen Port as the Endpoint port.
You can opt to use a random port in that case set Listen Port to 0.
5. MTU will be calculated automatically s (for IPv4 only 1440 (or 1432 for PPPoE), if IPv6 is used
that will be 1420 (1412 for PPPoE)).
If you provider also supports IPv6 or networks in between but you are not then you should
choose 1420 instead of 1440 (or 1412 for PPPoE), otherwise you will get MTU problems (see
troubleshooting section of the WireGuard Server setup guide)
6. Local Public key: Leave alone, only important for providers wanting your local Public Key then
this is the one to upload to your provider (after you click the Generate Key button)
7. DNS servers via tunnel: 10.100.0.1 this is optional if you want to use the DNS server from the
from the provider.
8. Enable Advanced Settings to enter the Private key
9. Local Private Key, copy the Private Key from the settings file in the box (it is easier to first
delete the contents if there is already a prior Private Key):
2EzUYqrpv/FP6f31h7Zsi2wii3YdiwlGtFSGJmW+a2c=
(the corresponding local Public key will become visible after Save and Apply Settings, after the key has
been calculated and after changing the page).
10. IP address/Netmask: 10.100.0.139/24 , although /32 is specified DDWRT works best with a
subnet of /24. Always use CIDR notation.
Older builds have separate boxes for IP address and Sub netmask, for converting your netmask from
CIDR ( /xx) to dotted decimal (xxx.xxx.xxx.xxx), you can use this conversion table or his this calculator
tool.
So in this case it should be 255.255.255.255. But usually it works best with just using 255.255.255.0. I
think that holds true for all providers but I have not tested them.
The end result:
Save and Apply Settings
Step 5 setting up the Peer

1. Click: Add Peer
2. Give the Peer a name, replace Peer with the name of your choice, I chose KeepSolid because
that is my provider 😊
3. Endpoint: Enable
4. Endpoint Address : port: 77.81.98.70 : 51820
5. Allowed IP's: 0.0.0.0/1,128.0.0.0/1 (addresses are in CIDR notation and comma delimited)
(if you use 0.0.0.0/0 then that must be converted, so it will work but better use
0.0.0.0/1,128.0.0.0/1).
6. Route Allowed IP's via Tunnel: Enable
7. Persistent Keepalive: 25
8. Peer Public Key: gAyw0BluPeJFrKNSuieYdTQXGttf2rNVU1Rg3VrP5Sk=
9. Use Pre-share key (not all providers use this): Enable
10. Pre-Shared Key: Ag+IEIT5CgVwpwDppzfjbxtnyaqVWJn35z7+gjaT6co=
11. Save and Apply Settings
It is good custom to do a reboot but it usually also works without.
Step 6 checking connection

To check a connection first look in the WireGuard Status window, press F5 (some browser need
CTRL + F5) to refresh or just change pages/tabs.
Here you can see that a handshake has taken place and traffic is flowing in both directions.
Next check if routing is OK and your clients are indeed using the tunnel.
Use your web browser and see what your Public IP address is. (Take note: it can take 1-2 minutes
before the connection is established)
Instead of the public IP from your ISP it should show the IP address from the WireGuard server, in
this case it should be in Romania.
I use https://ipleak.net and https://dnsleaktest.com:
More information you can get when you use the Command Line interface (SSH/putty/telnet) to
connect to your router (login name is always : root) and do:
wg
You can see that the handshake took place and under transfer the traffic is flowing in both directions
DNS settings
DNS servers via tunnel

The option DNS servers via tunnel will let you set one or more DNS servers in a comma delimited list.
The specified DNS servers are used by DNSMasq for the whole router and the queries via these
specified server(s) are always routed via the VPN tunnel.
So all attached clients will use these DNS server(s) via the VPN tunnel.
If you are using Policy Based routing and you do not want that all clients are using these DNS servers
via tunnel then you can use Split DNS and leave this field empty.
Note:
1. Do not set a DNS Server if you do not use DNSMasq e.g. if on Basic Setup page "Use dnsmasq
for DNS" or on Services Page "Enable dnsmasq" is disabled.
2. DNS works best if you disable Query DNS in Strict Order.
3. Wireguard uses the built-in DNSMasq, so this is not compatible with other DNS systems like
Unbound, Smart DNS, DNScrypt etc.
4. Wireguard relies on the use of resolv.dnsmaq, so do not use the no-resolv directive in
DNSMasq.
5. To avoid DNS leaks make sure Ignore WAN DNS on Setup page is enabled/checked.
6. It is good practice to set at least two DNS servers in Static DNS 1 and 2 on Setup page.
7. Some DNS servers of VPN providers are really slow, if you experience DNS problems you can
add a known good public DNS server which you trust in the DNS servers via tunnel field
For some further reading about DNS (DNS leaks, routing of DNS servers, adding extra DNS servers,
Split DNS etc.) see the VPN and DNS guide:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=331017
Options settings
Firewall Inbound: Enabled (checked)

For a commercial VPN provider it is advised to Enable (check) the inbound firewall for extra security,
note that when using WireGuard as a server that will block incoming traffic thus the server will not
work.
Kill Switch: Enabled (checked)

A kill switch is used if you want to block traffic of your LAN clients going out of the WAN interface.
Actually the same kill switch is used as for OpenVPN.
The Kill switch is intelligent, meaning that when PBR is used, only the IP addresses in the PBR field are
blocked from accessing the WAN, if you do not use PBR all traffic coming from clients are blocked
going out of the WAN.
Important notice:
1. On builds before 47074 the kill switch only works on clients connected to the default br0.
If you are using an earlier build and you have made unbridged VLAN's or VAP's you have to
add a manual kill switch substituting br0 with you own bridge!.
Starting with build 47266 the killswitch also works on a Wireless Access Point(WAP).
2. The kill switch is disabled if you manually disable WireGuard.
3. Always check if the kill switch is working!!,.
The easy way is to use wrong settings in the allowed IP's e.g. use: 0.0.0.1/1, 128.0.0.1/1, this
will cause the routing not to work and you should have no internet if the kill switch works..
When using PBR (only working for build 47074 or later!) you can check by deleting the
routing of the tunnel from the CLI (telnet/Putty) with:
ip route del 0.0.0.0/1 table 21
ip route del 128.0.0.0/1 table 21
Assuming you are using the first tunnel (oet1)
Make sure to set settings back and Save and Apply the tunnel and/or reboot to get a
working state again.
If you want to use port forwarding or only want a killswitch on certain interfaces, you have to disable
the built-in killswitch and make a manual entry in Administration/Commands, Save as Firewall:
iptables -I FORWARD -i br1 -o $(get_wanface) -m state --state NEW -j REJECT --reject-with icmp-host-
prohibited
(You can use a wildcard e.g. br+ to identify all brx interfaces or use another appropriate interface like
wlan0.1 etc. or even leave the in interface out entirely)
There are rare occasions when the WAN interface is not correctly identified, then you can use the
following
rules from @eibgrad using the routing table to discover the WAN port:
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
The built-in kill switch will automatically block IP addresses and other entries in the PBR field, if
necessary you can manually set the killswitch with e.g.:
When you are using Policy Based Routing (192.168.1.100 and 192.168.1.64/26 are the IP addresses in PBR):
iptables -I FORWARD -s 192.168.1.100 -o $(get_wanface) -m state --state NEW -j REJECT
iptables -I FORWARD -s 192.168.1.64/26 -o $(get_wanface) -m state --state NEW -j REJECT
When you are using a WAP:

iptables -I FORWARD -i br0 -o br0 -j REJECT
When you are using a WAP with Policy Based Routing (192.168.1.100 and 192.168.1.64/26 are the IP
addresses in PBR):
iptables -I FORWARD -i br0 -s 192.168.1.100 -o br0 -j REJECT
iptables -I FORWARD -i br0 -s 192.168.1.64/26 -o br0 -j REJECT
Route-up and Route-down scripts

The route-up and route down scripts are for special purposes and take a filepath and filename to a
script, i.e. /jffs/scriptup.sh
You can make use of permanent storage from a USB stick or Enable JFFS2 (Internal flash storage) on
Administration page, use HEREDOC to create scripts in /tmp from Administration/Commands Save as
startup)
Allow Clients WAN Access

This is mainly used when you use WG as a server or setting up for a site-to-site setup, see the Server
Setup guide. So disable (untick) for normal client use.
Bypass LAN Same-Origin Policy
This is mainly used when you use WG as a server or setting up for a site-to-site setup, see the Server
Setup guide. So disable (untick) for normal client use.
Policy Based Routing

Policy Based Routing (PBR) works by creating multiple routing tables and rules that specify which
routing table to use when certain criteria are met.
Criteria for routing decision can be source- and destination address, port, interface, fwmark etc. see:
ip rule man page
Source Based routing
The Source Routing (PBR) setting is a drop-down box with three choices:
Route all sources via VPN

This is the default where everything is routed via the VPN and actually means No PBR
Route Selected sources via VPN:

If you choose this, more options will become available i.e. Split DNS and the entry box for Policy
Based Routing.
This is the classic PBR where everything entered in the PBR box will be route via the VPN, everything
else is routed via the WAN.
In the PBR box you can add not only IP addresses (CIDR notation) but also source port (sport)
destination port (dport) In-interfaces (iif) e.g. br1 etc, see the ip rule MAN page
Items are entered as a comma delimited list (no comma at the beginning and none at the end), CIDR
notation is used.
Entries starting with # are skipped.
A range of IP-addresses can be written with the help of CIDR notation.

Optional,to make it easier to work with CIDR, group your IP addresses by doing the following:
1. On Setup page set DHCP start address to 192.168.1.64 for a Maximum DHCP users of 64
Your DHCP users will now be in the range .64- .127, which translates to a CIDR notation of
192.168.1.64/26
2. For all your local LAN clients you want to use the VPN set a static lease in the range .128-
.191 this translates to 192.168.1.128/26
3. For all your local LAN clients you do not want to use the VPN but the WAN set a static lease
below .64
In the PBR field enter for respectively the DHCP range and the static leases from .128 - .191:
192.168.1.128/26, 192.168.1.64/26
You can also include a specific destination address to route via the VPN e.g. if you want only to route
this specific IP address: 208.79.209.138 (whatsmyip.org) through the VPN from your whole subnet
then enter in the PBR field:
192.168.1.2/24 to 208.79.209.138
You can specify a whole in-interface to use the VPN with CIDR notation e.g. 192.168.2.0/24 but it is
easier to use the interface name (e.g. br1, wl0.1, wlan1.1 etc), the interface has to be unbridged to
work and some routers have problems with it so when in doubt just use the subnet to route:
iif br1
or
iif wl0.1
You can also specify a certain ports to use your VPN e.g. for transmission with sport (source port)
like:
sport 51413
For a quick check you can point your web browser to ipleak.net
Everything entered in the Policy Based Routing box is an ip rule which is set on table 2X (X is the
tunnels number) and can be checked (from CLI telnet/Putty) with:
ip rule show
ip route show
ip route show table 2X (X is the tunnels number)
Routed selected sources via the WAN

This does the opposite, everything entered in the PBR box will be routed via the WAN and everything
else will be routed via the VPN.
This can be useful if you have only a few IP addresses you want to route via the WAN and is also very
useful if you also run a concurrent WireGuard or OpenVPN server.
As the WireGuard/OpenVPN server must be using the WAN you can add sport 1194/51820 and now
this port will be using the WAN., e.g.:
sport 1194
You can make it universal (only for recent builds) with for OpenVPN server add to the PBR field:
sport $(nvram get openvpn_port)
For a WireGuard server (if it is the first tunnel you are using as Server) add to the PBR field:
sport $(nvram get oet1_port)
Destination Based Routing

Destination Routing can be used to route a certain destination, , e.g. a Domain name/URL/IP Address
range, always via the WAN or the VPN.
Destination routing is independent from Source routing.
This is a comma delimited list which can take IP addresses in CIDR notation and domain names
(starting with build 48214).
Route selected destinations via WAN
Sometimes you are using the VPN but have some destinations you always want to use the WAN in
that case you can enter that destination here.
It is often asked of this can also be done for e.g. Amazon, Netflix, BBC etc.
Unfortunately Amazon (and Netflix, BBC, Youtube etc) have multiple rapidly changing servers and
multiple domains which you have to catch all and the domain name is only resolved when the tunnel
is started so in reality this probably will not work.
IPSET might be able to mitigate this (for an example see:
https://www.linksysinfo.org/index.php?threads/using-ipset-to-bypass-a-vpn.73136/page-2
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327102&highlight=youtube )
Upcoming builds will have the ability to use IPSET in combination with WireGuard.
Ipset path and filename: Enter the path and name of your IPSET, the name is the name of your IPSET,
the path and name can be used to store the ipset file.
If you do not have permanent storage use: /tmp/IPSET_NAME
If you want to store between reboots you have to use permanent storage e.g. jffs2 or a USB stick and
set the path accordingly.
Ipset restore from file : Enable/tick if you want to keep your IPSET list when restarting the tunnel or, if
you have permanent storage, between reboots.
Ipset domains: a comma delimited list of domains, subdomains should also automatically be addeted.
Route selected destinations via the VPN

This can be used if you have destinations for which you always want to use the VPN if you connect to
those.
As an example, If you are using the DNSMasq method for Split DNS you can set the used DNS server
here so that that is routed via the VPN
Split DNS
When you are using PBR you might also want to route DNS queries accordingly e.g. you split DNS.
Often necessary for websites which not only track your IP address but also your DNS address e.g.
Netflix, Amazon, your bank etc.
The field where you can enter the DNS server(s) will appear if you enable Split DNS.
Source routing
In case you have chosen Route selected sources via VPN meaning the sources from the PBR field are
routed via the tunnel and other sources via the WAN, the PBR sources will use the DNS address from
the IPv4 DNS server field (and if you use IPV6 the IPv6 DNS server)
Make sure that the DNS server(s) you have chosen is different from the ones used elsewhere e.g. in
Static DNS 1,2,3!.
If you use Split DNS then leave the field DNS servers via tunnel empty as it is non-functional when
Split DNS is set .
All other sources will use the regular DNS servers from Static DNS 1,2,3 on Setup page.
In case you have chosen Route selected sources via WAN meaning PBR sources are routed via the
WAN and all other sources via the tunnel, the PBR sources will use the DNS server from Static DNS 1,
all other sources , which are routed via the tunnel will use the DNS server(s) from the IPv4/IPv6 DNS
Server field.
Destination routing
If necessary you can also use Split DNS when you are using Route selected destinations
For this we want to query all domain names in the Route selected destinations via a different DNS
server and route that DNS server via the WAN.
Add in the DNSmasq Additional Options on the Services page:
server=/netflix.com/amazon.com/1.0.0.1@vlan2
This tells DNSmasq to use DNS server 1.0.0.1 for those domains and use the WAN interface which is
specified with the @vlan2 (vlan2 is my WAN interface but yours might be different, you can query
which WAN interface you use from the CLI with: get_wanface , if you route via the VPN you have to
add the vpn interface e.g. @oet1 ).
Failover member/Watchdog
Starting with build 47621 you can set one or more client tunnels in a fail over group.
If one tunnel is down the next tunnel will be started, if the last tunnel fails (so you can also set only
one tunnel) WireGuard is resetted or the router is rebooted GUI options for further configuration
e.g. Ping address, Ping interval, start with random tunnel, will be added later).
The Watchdog has three restart options:
Default is just restarting the WG interface and restarting the WG related firewall rules so as to
minimize disturbance of other traffic.
The second option is to restart the whole firewall by setting an nvram variable:
nvram set wg_onfail_reboot=2
The third option is to reboot the whole router:
nvram set wg_onfail_reboot=1
Note: The WireGuard watchdog starts about 2 minutes after WireGuard is up to make sure that the
router is fully booted and can establish a connection.
When available in your GUI, you can set the address the watchdog uses to Ping to your liking, default
is 8.8.8.8.
Instead of a Server IP to Ping to you can also set a host-name and add a number of IP addresses to
said host-name in DNSMasq Additional Options.
This has the added benefit that DNSMasq will use a round robin method to use all the IP addresses so
that you will not risk a ban for too frequent pinging and it also adds redundancy if one ping ip
address is down.
See ninth post by @eibgrad: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=331461
This can be useful if VPN server goes down (for maintenance, failure or overcrowded) and you are
disconnected. By setting multiple tunnels in a Failover group the next tunnel is started automatically
and when the last tunnel fails WireGuard is restarted or the whole router is rebooted.
This can also be useful if you run your own VPN server which has a dynamic IP address, as the
address is only resolved when the tunnel starts your client does not know the new address unless the
tunnel restarts.
By setting your tunnel as only member in the failover group WireGuard will be restarted on
connection loss and the new IP address of the server will be resolved.
Testing
You can simulate a failing server by stopping traffic from the router to the server with
iptables -I OUTPUT -d server-ip-address -j REJECT
(remove the rule by replacing the -I (capital i)with a -D
Note: also when running tunnels in a fail over group it is important that the Local Listen Port, Public
keys and IP addresses are unique!
Switching between tunnels

IF you have setup multiple tunnels and want to switch between the one you use you can of course
use the GUI to enable/disable the tunnel.
You can also ssh and script this (you can make your own toggle script etc., this is only to show the
necessary commands):
nvram set oet1_en=0 #disable oet1
nvram set oet2_en=1 #enable oet2
nvram commit #make changes permanent
#(Re)starting WireGuard:
/usr/bin/wireguard-restart.sh
Under normal circumstances it is not necessary to restart the whole firewall and as that will stop
other traffic also it is normally not done. But in some circumstances it is necessary (e.g. NAT loopback
problems). The restart of the firewall will also trigger restart of Wireguard.
service firewall restart #optional not necessary under normal circumstances
/etc/config/eop-tunnel.prewall >/dev/null 2>&1
/etc/config/eop-tunnel.firewall >/dev/null 2>&1
Basic IPv6 support

Future builds will have basic IPv6 support, meaning there is no support for Policy Based IPv6 routing,
Killswitch, Bypass LAN Same-Origin Policy, Obfuscation yet.
Endpoint address can be a domain name which resolves to IPv4 or IPv6 (depends on the client) or an
IPv4 or IPv6 address (no brackets necessary):
Interface address supports settings dual IPv4 and IPv6 addresses:
Allowed IP's support IPv6 addresses, routing/allowing everything for IPv6, equivalent to 0.0.0.0/0 is:
::/0 (two double dots meaning all zero's/0 which is translated into ::/1, 8000::/1).
If you do not want to route/allow everything at least you should allow the WG subnet:
Nat out for IPv6 via the WireGuard (oet) interface is working.
Not working yet Killswitch, PBR, Bypass LAN Same-Origin Policy, Obfuscation.
If you experience problems please send a detailed report so that we can identify and solve the
problem.
Troubleshooting
Unfortunately WireGuard is not a chatty protocol (that is because of safety) so it works or does not
and it is not telling you why not ☹
It can take some minutes before the interface comes up so be patient.
If it is not working then just carefully check your settings, you can check if you entered the right
private key also from the command line: wg showconf oet1
For some more troubleshooting tips see the Troubleshooting section in the WireGuard Server setup
guide
Deleting INVALID rules

iptables -D FORWARD -o $(get_wanface) -p tcp ! -s $(nvram get wan_ipaddr) -m state --state
INVALID -j DROP
iptables -D INPUT -m state --state INVALID -j DROP
ip6tables -D INPUT -m conntrack --ctstate INVALID -j DROP
Miscellaneous
For builds prior to 43045 you can set the private key manually, you can do this by telnetting/Putty to
your router and do (do not enter the [] ):
nvram set oet1_private=[privatekey]
nvram commit
After this Reboot.
(This assumes that this is the first Wireguard tunnel (oet1) which is running on your router, when in
doubt see the next steps to see if your interface is indeed oet1).
Port forwarding via WireGuard (oet) interface
This is an example to port forward via the oet interface which might come in handy if you are
connected via the oet interface to a server and you want to port forward, this is an example where I
chose port 444000 to port forward to port 80 on 192.168.1.1 and assuming you are using the first
tunnel e.g. oet1.
#!/bin/sh
ext_port=444000
int_port=80
int_ip=192.168.1.1
tunnelnr=1 # adjust for used tunnel number first tunnel is 1
iptables -t nat -D PREROUTING -p tcp -d $(nvram get oet${tunnelnr}_ipaddr) --dport $ext_port -j DNAT --to
$int_ip:$int_port
iptables -t nat -D PREROUTING -p udp -d $(nvram get oet${tunnelnr}_ipaddr) --dport $ext_port -j DNAT --
to $int_ip:$int_port
iptables -D FORWARD -p tcp -d $int_ip --dport $int_port -j ACCEPT
iptables -D FORWARD -p udp -d $int_ip --dport $int_port -j ACCEPT
#For FORWARDING to LAN Clients

iptables -t nat -I PREROUTING -p tcp -d $(nvram get oet${tunnelnr}_ipaddr) --dport $ext_port -j DNAT --to
$int_ip:$int_port
iptables -t nat -I PREROUTING -p udp -d $(nvram get oet${tunnelnr}_ipaddr) --dport $ext_port -j DNAT --to
$int_ip:$int_port
iptables -I FORWARD -p tcp -d $int_ip --dport $int_port -j ACCEPT
iptables -I FORWARD -p udp -d $int_ip --dport $int_port -j ACCEPT
#To allow to connect to processes on the router itself e.g. remote administration, lighttpd etc:
iptables -D INPUT -i oet${tunnelnr} -p tcp --dport $int_port -j ACCEPT
iptables -I INPUT -i oet${tunnelnr} -p tcp --dport $int_port -j ACCEPT
Test this script from the command line and if it works: Administration/Commands and Save as Firewall
Furthermore Disable CVE mitigation in the GUI and probably disable SFE (Shortcut Forwarding Engine)
on Setup page.
Note
For some providers the oet endpoint address is not the same as the exit address (the address you use to
connect from the outside).
You can look for the exit address with ipleak.net or dnsleaktest.com.
You can use DDNS on the router to keep track of the exit address in case it changes, make sure you have
Use External IP check enabled, take care if you are using Policy Based routing that the router is routed
via the tunnel.
Running concurrent with OpenVPN Client.

When you also run an additional OpenVPN client tunnel besides WireGuard tunnels, then OpenVPN
can get confused and does not know what the default gateway is although the default route is intact
(default route via the WAN interface).
OpenVPN can then start routing to the remote/server ip via the oet interface. To stop this routing
add in the OpenVPN Client Additional Config: redirect-private local
References
Running script via remote SSH:
https://forum.dd-
wrt.com/phpBB2/viewtopic.php?t=328294&sid=3bd86fbc78f6e4607584a9563b539275
Custom PBR script

If you want to add your custom PBR script with a lower priority (so that it is executed first) add a
custom PBR script to the Route-up script of the last tunnel.
One way to do this is to add the following to Administration commands and Save as Custom.
An example of a custom PBR script is routing port 22 (SSH) always via the WAN:
#custom PBR routing table
#choose table nr
TID="table 19"
#delete before making new
while ip rule delete from 0/0 to 0/0 $TID >/dev/null 2>&1; do true; done
ip route flush $TID
#set rules
ip rule add sport 22 $TID
#set routes
ip route add default via $(nvram get wan_gateway) $TID
In the Route-up script box of the last tunnel add:

/tmp/.rc_custom
Specific Provider Settings
TorGuard
Setup: https://torguard.net/knowledgebase.php?action=displayarticle&catid=55&id=263
Portforward: https://trash-guides.info/Misc/How-to-setup-Torguard-for-port-forwarding/
Mullvad
https://mullvad.net/nl/account/#/wireguard-config/
1. Login with your account number
2. Click on upper right corner "Manage Ports and WireGuard Keys":
3. On the Manage Ports and WireGuard keys page click on "WireGuard Configuration file"
4. On the WireGuard configuration file generator select "Linux":
5. Open the Managed keys by clicking on the \/ arrow:
6. Now enter the private key you have generated on the DDWRT router, put that in the box and
click "import key".
Alternatively you can let Mullvad make the key pair and then you will get the private key
from the configuration file in the downloaded zip archive (see below)
7. Select the Location and servers
8. Open Advanced Settings
9. Select IPv4 only and set a custom port
10. Download the zip archive
11. Open the zip archive and setup the router according to the WireGuard client setup guide
Private Internet Access (PIA)
PIA does not directly support WireGuard on the router but with some workarounds it is possible see:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=330429
Code on pastebin:
https://pastebin.com/Sri2f1wM
https://github.com/pia-foss/manual-connections
Reverse engineering:
https://github.com/hsand/pia-wg
https://github.com/pia-foss/manual-connections
Thanks to @portsup!
Cloudfare Warp
https://github.com/ViRb3/wgcf
NordVPN
With some tricks as they do not support it directly:
https://forum.openwrt.org/t/instruction-config-nordvpn-wireguard-nordlynx-on-openwrt/89976
For MacOS:
https://www.reddit.com/r/WireGuard/comments/xqz102/extract_nordvpn_wireguard_config_with_
macos_no/
IVPN
https://www.ivpn.net/setup/router/ddwrt-wireguard/
Do not set the DNS servers in Static DNS but simply place those in the DNS via Tunnel field
Oracle Cloud setup

https://www.youtube.com/watch?v=ocsVUGjVSpI
https://pimylifeup.com/raspberry-pi-wireguard/
https://pswalia2u.medium.com/setting-up-personal-wireguard-vpn-on-oracle-cloud-compute-
instance-1d90d56d4b8b
https://unix.stackexchange.com/questions/653495/oracle-free-tier-wireguard-and-iptables
Proton
Proton now supports WireGuard on the router e.g. you can make and download a conf file.
On the download page (which you can view if you have made a free account and are logged in) scroll
down to the bottom to make your conf file for the router.
Make sure to set Persistent Keepalive to 20 or 25.
Note the free conf files expire usually the next day.

DDWRT WireGuard Client Setup Guide v37

Uploaded by

Copyright:

Available Formats

DDWRT WireGuard Client Setup Guide v37

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DDWRT WireGuard Client Setup Guide v37

Uploaded by

Copyright:

Available Formats

DDWRT WireGuard Client setup guide

Latest version see: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624

To work with this guide DDWRT build 52242 or higher is mandatory.

Then click Generate and download the setup file.

Step 2 Setup file

When you are done click Apply Settings.

To setup manually proceed with step 3.

Step 3 setup the WireGuard Tunnel manually

From the setup file fill in the right settings:

Save and Apply Settings

Step 5 setting up the Peer

Step 6 checking connection

DNS servers via tunnel

Firewall Inbound: Enabled (checked)

Kill Switch: Enabled (checked)

When you are using a WAP:

Route-up and Route-down scripts

Allow Clients WAN Access

Policy Based Routing

Source Based routing

Route all sources via VPN

Route Selected sources via VPN:

A range of IP-addresses can be written with the help of CIDR notation.

Routed selected sources via the WAN

Destination Based Routing

Route selected destinations via WAN

Route selected destinations via the VPN

Switching between tunnels

Basic IPv6 support

It can take some minutes before the interface comes up so be patient.

Deleting INVALID rules

#For FORWARDING to LAN Clients

Running concurrent with OpenVPN Client.

Custom PBR script

In the Route-up script box of the last tunnel add:

Specific Provider Settings

4. On the WireGuard configuration file generator select "Linux":

5. Open the Managed keys by clicking on the \/ arrow:

Oracle Cloud setup

Make sure to set Persistent Keepalive to 20 or 25.

You might also like