DDWRT WireGuard Advanced Setup

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

Introduction
This is an accompanying guide to the WireGuard server setup guide and the WireGuard client setup guide. Read
those first.
Just as WireGuard is a work in progress so is this guide and thus not free from bugs or errors.
Please report your remarks, inconsistencies or questions in the Advanced Networking Forum or PM me (Personal
Mail). Only with your help can this become a useful guide.

This guide assumes you have a general knowledge about network setup and routing and already know how to setup
WireGuard in general.

To work with this guide DDWRT build 49492 is mandatory.

Note an MTU size of 1460 as shown is too high do not go over 1440 and depending on setup you should go even
lower (if IPv6 is used along the way subtract 20, if PPPoE is used subtract 8)
See Forum guidelines where to download firmware.
WireGuard is usually available on routers with 8 MB and over Flash RAM using at least Kernel 3.10 (so not on K2.6
builds)

Table of Contents
Introduction ...................................................................................................................................................................... 1
WireGuard on a WAP ........................................................................................................................................................ 2
Server on the WAP ........................................................................................................................................................ 2
Connection to the clients network from the server side: ............................................................................................. 4
Troubleshooting ............................................................................................................................................................ 5
Client on the WAP ......................................................................................................................................................... 6
Client side, setup local LAN clients to use the WAP ..................................................................................................... 7
Connecting to server side for clients with default gateway ......................................................................................... 9
WireGuard setup on Station (Repeater/Client) mode .................................................................................................... 10
Site-to-Site between multiple sites Hub and Spoke ....................................................................................................... 11
Client site B setup ....................................................................................................................................................... 11
Client site C setup ....................................................................................................................................................... 13
Server site A setup ...................................................................................................................................................... 14
Roaming client (Phone/Laptop/Tablet) ...................................................................................................................... 15
Site-to-Site between multiple sites "Mesh".................................................................................................................... 16
One Server, One client, two Tunnels, Policy Based Routing ........................................................................................... 20
First tunnel .................................................................................................................................................................. 20
Second tunnel ............................................................................................................................................................. 20
Policy Based routing .................................................................................................................................................... 20
Client with two peers one to VPN provider other to own server ................................................................................... 21
Bridging Solution ............................................................................................................................................................. 26
Addendum 1 example of /jfss/etc/smb.conf .............................................................................................................. 28

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 1

WireGuard on a WAP
Wireless Access Point (WAP) (basically a secondary router with LAN<>LAN connection, router in the same subnet,
with DHCP and WAN disabled, Local DNS and Gateway pointing to primary router and router left in Gateway mode),
can be used as a WireGuard Server and Wireguard Client.

A Wireless Access Point (WAP) is a secondary router connected wired LAN<>LAN on the same subnet as the primary
router below my setup instructions.
On Basic Setup page:
• WAN disabled
• DHCP server Disabled (=off and NOT set as Forwarder!)
• Local IP address in subnet of primary router but outside DHCP scope, make sure the used IP address is
unique on your network you cannot have duplicates.
You can run udhcpc to give the WAP a static lease but because you can it doesn't mean you should ;)
• Gateway and Local DNS pointing to primary router
• DNSMasq enabled
• Router kept in the default Gateway mode (the wiki says Router mode but do not do that, either it does not
matter (this case) or break things)
• Connect LAN <> LAN (do not use the WAN port unless you really need that extra port, for most routers
traffic still must use the CPU so performance is lacklustre )
• I do not change the Firewall settings although you do not want a firewall, the Firewall is automatically
disabled as there is no WAN, but it does not hurt to follow the wiki and Disable the Firewall anyway.

You have to add the following rule to the firewall in order to get internet access from clients attached to the VAP.
In the web-interface of the router (the WAP): Administration/Commands save Firewall:
#Always necessary (alternatively set static route on main router and NAT traffic from VAP/Bridge out via WAN):
iptables -t nat -I POSTROUTING -o br0 -j SNAT --to $(nvram get lan_ipaddr)

Server on the WAP

I use the following setup to illustrate the setup.
• Primary router on 192.168.1.1
• WAP connected to primary router with IP address of 192.168.1.5
• Client is DDWRT router with subnet 192.168.4.1
• Port forward has been set on the primary router to the WAP (e.g. port 51810 to 192.168.1.5)
• WireGuard server 10.4.0.1 / 255.255.255.0
• WireGuard client 10.4.0.4 / 255.255.255.0
• Both client and server have generated their keys by pressing the Generate key button
• Local Public key from server is copied to the Peer public key of the client and vice versa

Clients can be anything connected from the internet, for setup see the WireGuard client setup guide.
I use a DDWRT router for client in this example as to also show you how to setup return traffic from the servers
network to the client's network.
When you want to use regular roaming clients (like your phone) see the WireGuard server setup guide)

This setup requires advanced networking expertise

Server setup:
• WireGuard network 10.4.0.0
• Server 10.4.0.1 netmask 255.255.255.0
• Local Port used is 51810
• Allowed IP's are the clients Wireguard IP address and the local subnet of the client, route Allowed IP's is
enabled so that you can reach the clients subnet (192.168.4.0/24) from the server side.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 2

Client setup
• Client is 10.4.0.4 / 255.255.255.0
• The Peer Public key is the Local Public Key of the server and vice versa
• Endpoint with the DDNS address or IP address of the primary router with port 51810
• CVE and NAT are disabled (therefore we have to allow the subnets and set routes on both side to route the
respective subnets via the tunnel)
• Allowed IP's 0.0.0.0/1,128.0.0.0/1 meaning all traffic from the client side will go through the tunnel and to
the server, alternatively if you only want to reach the server use (10.4.0.1/32, 192.168.1.0/24)
• Persistent Keepalive: 20

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 3

Connection to the clients network from the server side:
This can be done in two ways, the first way is better suited when we reverse the situation and use the WAP as a
client and want to route all traffic through it, but for this setup use option 2.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 4

 1. Point the local gateway of your client to 192.168.1.5 (the WAP) instead of the primary router( 192.168.1.1),
you can even use DNSMasq on the primary router to handout different gateways to different clients (but
that is outside the scope of this guide)
2. Set a static route on the primary router (your gateway) redirecting the traffic for the clients
subnet(192.168.4.0/24 to the WAP see the next picture:

Troubleshooting
See WireGuard server setup guide at the back of the guide

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 5

Client on the WAP
Client setup
This is the reverse, the client is situated on the WAP, but it can also be used for a wireless bridge (Station or
Repeater Bridge), this can also be used for a connection to a commercial server/provider. For instructions see the
WireGuard client setup guide.
• NAT via Tunnel: Enable (necessary for commercial providers, to make a connection to our own server you can disable
it, but then you have to take care to NAT the clients subnet traffic out onto the WAN interface)
• Allowed IP's: 0.0.0.0/1,128.0.0.0/1
• Route Allowed IP's enabled so that all traffic is routed via the tunnel
• Endpoint address: servers address and port

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 6

(Alternatively set a static route on the primary router for the Wireguard subnet to the WAP)

Client side, setup local LAN clients to use the WAP

On the client side the WAP now routes all its traffic to the server but LAN clients do not use the WAP as gateway,
they use the primary router.

To let the client side LAN clients use the WAP as gateway you can manually set the gateway on the LAN client to
point to 192.168.1.5 (IP address of WAP) instead of the default 192.168.1.1.

For instructions how to use DNSMasq on your primary router to handout an alternate gateway and more options to
change the gateway, see the VPN and DNS Guide , paragraph "Using DNSMasq to specify Alternate DNS
servers/Gateway for specific clients"

Note: An unbridged VAP on the WAP will always use the WG tunnel without the need for client side gateway settings
so that using that makes it easy to use the WG tunnel.

Server setup
The server has the clients WireGuard IP and the clients subnet in the Allowed IP's and has routing enabled so that
the clients subnet can be reached from the server side.
The following picture shows all relevant settings.
If you have trouble keeping the connection active then setting persistent keepalive also on the server side
sometimes helps.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 7

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 8
Connecting to server side for clients with default gateway
For client side LAN clients which are not routed via the WAP it is still possible to reach the server side if you set a
static route on the primary router, routing the servers subnet via the WAP:

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 9

WireGuard setup on Station (Repeater/Client) mode
WireGuard should function without any problem when the router is setup in Station mode (where the WAN is one of
the radio's).
https://wiki.dd-wrt.com/wiki/index.php/Wlan_Repeater
https://wiki.dd-wrt.com/wiki/index.php/Client_Mode

IF you encounter problems turn off Acceleration options Like CTF and SFE (Short Cut Forwarding Engine) on Setup
page) and /or lower MTU value (see the Troubleshooting section of the WG Server Setup guide)

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 10

Site-to-Site between multiple sites Hub and Spoke
This is a setup which connect one server and two clients via the internet so that each site can reach the other two
sites. This is the hub and spoke setup where there is one central server with multiple clients.
Alternatively you can use a mesh like setup with a many-to-many connection without a central server

Server site A
Linksys EA8500 running Community build 49492
Subnet 192.168.6.1/24
WG IP address: 172.21.21.1/24

Client site B
Linksys EA6900 (Xvortex CFE), running Community build 49492
Subnet: 192.168.13.1/24
WG IP address: 172.21.21.13/24

Client site C
Netgear R7800 running build 49492
Subnet: 192.168.5.1/24
WG IP address: 172.21.21.5/24

The basic principle is simple, client sites B and C connect just like a normal client to server site A.
They route traffic with a destination to A and to the other client through the tunnel, the server A takes care of the
routing between B and C.

In this example I wanted to only route traffic for the other sites via the tunnel and not the default traffic.

If you want to route all traffic through the tunnel from B and/or C so that the whole internet is reached via the
server, you enter in the Allowed IP's:
0.0.0.0/1,128.0.0.0/1.
As we do not use NAT you then also have to NAT traffic from the subnet of the client router out via the WAN
interface e.g. for Client B:
iptables -t nat -A POSTROUTING -s 192.168.13.0/24 -o $(get_wanface) -j MASQUERADE

Note that LAN clients can have their own firewall and do not always allow traffic from other subnets, so either
tweak the firewall of your LAN clients or NAT traffic out of the LAN interface (br0) by enabling Allow Clients Full LAN
Access
Downside, you will lose logging and access control as all traffic now originates from the routers IP address instead of
from the WG interface or the other subnet.
( iptables -t nat -I POSTROUTING -o br+ -s $(nvram get get oet${i}_ipaddrmask) -j MASQUERADE )

As the WG interface (oet) is unbridged there already is a NAT rule out on the WAN for the tunnels subnet

To NAT or Not
In this example we do not NAT the traffic from Clients and Server, so we can leave the CVE patch enabled.
Rule of thumb: if the clients uses NAT via the tunnel (like your phones or windows clients always do) then the CVE patch has to
be disabled on the server side.
So if our server A also want to have phones or windows clients as peers you have to disable the CVE patch (or use other
workarounds) for each of the sites you want to have access to the local clients from your phone or windows clients.
To make it easy on yourself start with the CVE patch disabled (this can have security implications albeit minimal (but that is my
personal opinion)

Client site B setup

On site B for Allowed IPs:
[WG tunnels subnet],[subnet of A], [subnet of C ]
DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 11
172.21.21.0/24, 192.168.6.0/24, 192.168.5.0/24
(Instead of the WG tunnels subnet you can also use: [WG IP address of A]/32, [WG IP address of C]/32. So to be more specific as
what traffic you want to allow )

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 12

Client site C setup
On site C that is the other client, for allowed IP's:
[WG tunnels subnet], [subnet of A], [subnet of B ]
172.21.21.0/24, 192.168.6.0/24, 192.168.13.0/24
(Instead of the WG tunnels subnet you can also use: [WG IP address of A]/32, [WG IP address of B]/32. So to be more specific as
what traffic you want to allow)

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 13

Server site A setup

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 14

On Server A you have two peers:

Peer B Allowed IP's:

Only allow the IP address of the tunnel of site B and site's B subnet
[WG IP address of B]/32, [subnet of B]
172.21.21.13/32,192.168.13.0/24

Peer C Allowed IP's:

[WG IP address of C]/32, [subnet of C]
172.21.21.5/32,192.168.5.0/24

As Route Allowed IP's is enabled there will be routes from B and C to A and via A to the other client, server A
connects to the routers with the right key/peer

Roaming client (Phone/Laptop/Tablet)

If you also want to add roaming clients to your Server A then head over to the WireGuard Server Setup guide.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 15

Site-to-Site between multiple sites "Mesh"
Although Mesh is a bit misleading in this context as there is no route-detection, no spanning tree or self-healing etc.
it is just a multi-point to multi-point setup.

The Hub and Spoke setup is easier to maintain you have one central hub to which all clients attach but you also have
one point of failure and also need considerable bandwidth if you have heavy traffic.

The alternative is that each client/node has a tunnel to all other clients. If you have more than a couple of clients this
can become an administrative nightmare but in the references are some tools to ease the burden.

With this multi-point to multi-point setup we can choose to have one tunnel with many peers or many tunnels with
only one peer

Multiple tunnels is easier to understand as far as routing and firewall rules are concerned.
If you want to check connection and use a watchdog use different ports or MTU you must use multiple tunnels/one
peer
https://www.reddit.com/r/WireGuard/comments/mdadt0/best_strategy_for_multiple_pointtopoint_tunnel/

The basic setup for one tunnel/multiple peers is just like a regular server setup (see the WireGuard Server Setup
guide) but instead of only listening you also set an endpoint to each peer and keepalive (we assume that all node are
reachable via the internet)

Note in my example I choose unique listening ports for each node which can be useful if the nodes share a public IP
address and you have to port forward, it is not necessary per se.

In allowed IP's for each peer you enter the WG IP address (/32) and the peers subnet, so basically this is (should be)
unique for each peer

Site A
Linksys EA8500 running Community build 49492
Subnet 192.168.6.1/24
WG IP address: 172.21.21.1/24
Listen Port:51810
Peers:

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 16

Site B
Linksys EA6900 (Xvortex CFE), running Community build 49492
Subnet: 192.168.13.1/24
WG IP address: 172.21.21.13/24
Listen port: 51813
Peers:

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 17

Site C
Netgear R7800 running build 49492
Subnet: 192.168.5.1/24
WG IP address: 172.21.21.5/24
Listen Port:51805
Peers:

References:
https://github.com/k4yt3x/wg-meshconf
https://github.com/gravitl/netmaker
https://git.zx2c4.com/wg-dynamic/about/

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 18

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 19
One Server, One client, two Tunnels, Policy Based Routing
This setup describes one tunnel setup to a commercial VPN provider and one tunnel setup as a server so that you
can access your network from the internet with a roaming client e.g. your phone or laptop on cellular.

First tunnel
Set this tunnel up like a standard WireGuard client using the WireGuard Client setup guide
Test the tunnel.

Second tunnel
Set this tunnel up as a standard WireGuard server using the WireGuard server setup guide.
Disable the first tunnel (no worries your settings are retained ) and test if you can reach your server Wireguard
server.

Note: the Listen Port of both tunnels should be different!

Policy Based routing

The problem with both tunnels active is that traffic coming in via the WAN with destination your WG server will be
routed out via the WG client to your VPN provider and the firewall will not allow that.

So we have to use Policy Based Routing on the WG client to make sure traffic for the WG server is going out via the
WAN.

Depending on your needs you can choose:

Source Routing (PBR): Routed Selected sources via the VPN
Under Selected sources you can just enter your whole network e.g. 192.168.1.0/24 so that all your LAN clients will
use the WG client
Source for PBR: <subnet>
See for some explanation the WG Client setup guide
Note that clients connected to your WG server are not routed via the WG client for internet access. If you want that
you have to add the servers subnet to the Source for PBR.

Alternatively you can only route the port of the WG server via the WAN:
Source Routing (PBR): Routed Selected sources via the WAN
Source for PBR: sport <Listen-port-of-WG-server>
Note that everything but your Local WG servers port is now routed via the VPN so also traffic form the roaming
client

The roaming client

When you setup your roaming client to connect to your WG server youcan suffice with only adding the routers
subnet in the allowed IP's e.g. 192.168.1.1/24.
So only traffic for your home network will go via the tunnel and everything else e.g. your internet traffic will take the
normal route.
If you want internet traffic to go via the tunnel and via your router then you can use 0.0.0.0/0.

Depending on your settings on the WG client on the router, the traffic from the roaming client (which is the WG
servers subnet) can take the WAN or take the WG client, see above.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 20

Client with two peers one to VPN provider other to own server
This setup is done on an experimental alpha build with built-in Policy Based Routing, Kill switch (which also
automatically protects the PBR addresses if PBR is used), Inbound firewall on the tunnel, Status Window and
possibility to name your peer.

Until then you can use a script for Policy Based Routing see the third post of this thread: WireGuard server setup
guide

Client Setup
Subnet: 192.168.5.0/24
Tunnel oet1: to VPN Provider using Policy Based Routing
Tunnel oet2: to own WG server (on subnet 192.168.1.0/24), using Policy Based Routing

Tunnel oet1 to VPN provider

This is a standard setup as described in the WireGuard client setup guide
Policy Based routing is done by entering the IP addresses in CIDR format in a comma delimited list.
If you start the list with # then PBR is deactivated. Entries starting with # are ignored.
PBR is not necessary per se, if you do not use it then all clients will default to use the VPN provider, you can reach
your own WG server by its IP address, but in this case I also want some client to use our own WG server for all the
traffic

CVE-2019-14899 Mitigation: Enable

Route Allowed IP's: Enable
Almost all commercial VPN providers need NAT via Tunnel Enabled and can also have the CVE mitigation Enabled.

Policy Based Routing

Policy Based Routing (PBR) will only route the IP addresses in the PBR field via the tunnel.
All other traffic will use the WAN.
The IP addresses are entered as a comma delimited list (no comma at the beginning and none at the end), CIDR
notation is used.
When the list starts with a #, PBR is disabled (so you can preserve the list), entries starting with # are not added.
I have entered my whole DHCP range (.64 - .127) so that all my DHCP clients are using this tunnel other IP addresses
are using the WAN

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)

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 and if you do not use PBR all LAN clients connected to br0 are blocked, a 'dangerous' option as
you are blocking all LAN clients from routing via the WAN so it can have unwanted side effects.
Take note: only traffic coming from clients connected via br0 are blocked so if you have made your own unbridged
interfaces you have to block them by hand!

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 21

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 22
Tunnel oet2 to own WG server

As this is setup to our own WG server NAT via Tunnel is Disabled, normally you can leave CVE mitigation enabled (as
our own WG server also has NAT disabled and rule of thumb: NAT disabled on one side means you can have CVE
mitigation Enabled on other side) but for reasons detailed below it is Disabled, but only read on if you like
complicated 😊
I have CVE mitigation disabled here because our own WG server also has roaming clients and I want those also to be able to
access this side e.g. our phone connects to our own WG server , that server has a route to this client which is made by this oet2
tunnel.
So with our phone connected to the WG server we can also reach anything on this client side, if we kept CVE mitigation enabled
our phone (which is using the tunnels subnet) could not reach this client side, only clients from the routers subnet
(192.168.0/24) can reach the client side when CVE mitigation is enabled.

Policy Based Routing

I have only one client specified, this client routes all traffic via the tunnel to our WG server.
The WG server (not detailed here) has an OpenVPN client with PBR and is routing all traffic coming in via the WG
tunnel and this specific IP address (necessary because this traffic it’s not NATted) out via the OpenVPN tunnel, so this
client 192.168.59.4 is using the WG tunnel to our own WG server and reaches the internet via the OpenVPN client on
the WG server.
Is this fun or what 😊

Kill Switch: Disabled (not Checked)

As we are not using the WAN there is no need/use for a kill witch

Firewall Inbound: Disabled (not Checked)

As we trust our own WG server and we want site-to-site traffic the inbound Firewall is disabled.

Route Allowed IP's: 10.4.0.0/24, 192.168.1.0/24, 0.0.0.0/1, 128.0.0.0/1

Normally we should allow the whole subnet of the tunnel to also allow other clients (like the phone connected to
our WG server) if we do not want that then we could only allow the WG server 10.4.0.1/32 and the servers subnet
(192.168.1.0/24).
As we want to have a client (192.168.4.59) to use this route as the default route we still have to allow all return
traffic hence the 0.0.0.0/1,128.0.0.0/1.

Route Allowed IP's: Enable

So that for all clients the WG server side is accessible, the routes (save the default routes like 0.0.0.0/1 and
128.0.0.0/1, PBR will not add them to the routing table) are copied to all routing tables.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 23

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 24
End result
One WireGuard client with two tunnels both using PBR.
All DHCP clients (192.168.4.64/26 will use the commercial VPN provider
One client 192.168.4.59 will use the second tunnel to our own WG server and traffic from this client is routed via our
WG server (with PBR), which routes traffic from clients connected via WG out via its OpenVPN client.

Clients on both WG-Server side and WG-Client side can communicate with each other.
(Note the individual firewall of the LAN clients have to allow traffic from the subnets involved, see elsewhere)

Roaming clients from the server side can also connect to clients on the Client side.

A complicated setup which shows what is possible while only using the GUI, no scripting needed, just some settings
(and some very heavy thinking)

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 25

Bridging Solution
Courtesy of @thewizard76

Wireguard is a low-overhead, modern VPN tunnel that is much faster than OpenVPN,
especially on low end devices. Its small public keys and easy configuration also
make it, in practice, more likely to be secure than OpenVPN.

However, as a layer 3 protocol based on cryptokey routing, WireGuard does not

natively support multicast or broadcast traffic, which interferes with local
peer discovery protocols -- such that those used for iOS/Android screen casting,
AirPrint, and so on -- basically all modern "it just works between devices"
protocols.

Further, WireGuard has no equivalent to the OpenVPN tap interface, and does not
support transport of non-IP (layer 2) traffic, which can be an issue for some
older and bespoke communication protocols.

Fortunately, there is an easy solution when both ends of the wireguard tunnel
support RFC3378 Ethernet over IP, for example when connecting two dd-wrt devices
to each other. The solution involves:

* Creating a WireGuard tunnel between the two devices as usual.

* Creating a RFC3378 Ethernet over IP tunnel that runs inside the WireGuard one.

To do so, follow these steps (start at step 15 if you already have a wireguard tunnel
for the endpoints you wish to connect):
1. On device A, go to setup->tunnels, and click add tunnel. Select type Wireguard,
select enable tunnel, and click save.
2. Disable NAT via tunnel
3. Change local port to any number other than the default (e.g. 51821)
4. If local public key is blank, click generate key, and copy the public key.
Call this device A's public key (e.g. it might be
nCrzG5s1rlq66EXZq/iG9KZgRDhplaLNAB1CAZc3v3w= )
5. Uncheck firewall inbound
6. Enter a tunnel IP address and netmask. Any private IP range not used elsewhere
in your configuration will do. For example, 172.23.0.1/24 for device A.
7. Click save. Then click add peer.
8. Enter the configuration info for device B into the peer section. For this
tutorial, device B will have a peer IP of 172.23.0.2, leave DNS as all 0's.
9. Enable endpoint and set the public IP and public port of device B
(e.g. deviceB.ddns.net : 51821).
10. For allowed IPs, make sure the peer IP is listed, e.g. 172.23.0.2/32 .
11. Enter the public key of device B as the peer public key.
12. Enable route allowed IPs via tunnel, and click save.
13. Repeat steps 1-12 on device B; call the public key in step 4, device B's public
key (e.g. xCJNIF1mtyuo6F9fbg/a+jyss1j0f6xt9Yqxlixzghw= ). In step 6, be sure
to use a different IP address, e.g. 172.23.0.2/24 . In steps 8-11, replace all
instances of device B with device A, e.g. 172.23.0.2-->172.23.0.1, deviceB.ddns.net
-->deviceA.ddns.net, etc.
14. Click apply on both devices. If properly configured, you should now have a
functioning point-to-point wireguard VPN tunnel between devices A and B.

15. On device A, go to setup->tunnels, and click add tunnel. Select type RFC3378,
select enable tunnel, and click save.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 26

16. For local IP, input the wireguard IP address of device A, 172.23.0.1 in the
example above. For remote IP, input the wireguard IP of device B, 172.23.0.2
in the example above.
17. Disable bridging. Then enter an IP address for device A on the RFC3378 tunnel.
Any unused private space will do, e.g. 172.21.0.1/24. Click
save, and then apply.
18. Repeat steps 15-17 on device B, swapping the addresses in step 16, and changing
the IP in step 17 to 172.21.0.2/24 .

At this point, congratulations, you now have a layer 2 tunnel connecting the two
endpoints, protected by wireguard encryption. Now you can use it for various
purposes.

If the goal is to enable the local discovery traffic for screen casting, media
servers, etc., then the best approach is to setup an avahi daemon on device A
and device B that reflects discovery traffic -- but not all broadcast traffic
-- via the RFC3378 tunnel. To do so, install avahi on both device A and device
B (either by entware, or e.g. by grabbing suitable executables for the devices
from the OpenWRT packages). Then configure Avahi to reflect between the local
traffic and the RFC3378 tunnel. A minimal configuration might be:

[server]
allow-interfaces=br0,oet2
[reflector]
enable-reflector=yes

Where br0 and oet2 are the interface names for the local subnet of the device,
and the RFC3378 tunnel respectively.

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 27

Addendum 1 example of /jfss/etc/smb.conf

192.168.1.1/24 is the routers subnet, 10.4.0.0/24 is WG subnet 10.8.0.0/24 is OpenVPN server subnet depending on
your setup this is not needed to add.
Adding interfaces vlan2 and eth0 is probably also not necessary
[global]
log level = 1
netbios name = R6400v2
server string = R6400v2s
syslog = 10
encrypt passwords = true
preferred master = yes
use sendfile = yes
aio read size = 2048
aio write size = 2048
large readwrite = yes
security = user
oplocks = yes
mangled names = no
max stat cache size = 64
workgroup = home
bind interfaces only = yes
guest account = nobody
map to guest = Bad User
smb passwd file = /var/samba/smbpasswd
private dir = /var/samba
passdb backend = smbpasswd
log file = /var/smbd.log
max log size = 1000
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=262144 SO_RCVBUF=262144
read raw = yes
write raw = yes
max xmit = 65536
dead time = 15
getwd cache = yes
lpq cache time = 30
min protocol = NT1
max protocol = SMB3_11
printing = none
load printers = No
usershare allow guests = Yes
smb3 encryption = no
hosts allow = 192.168.1.1/24, 10.4.0.0/24, 10.8.0.0/24
interfaces = br0, oet1, tun2, vlan2, eth0
[data]
comment = data
path = /mnt/sda1/
read only = no
guest ok = yes

force user = root

[jffs]
comment = jffs
path = /jffs/
read only = no
guest ok = yes

force user = root

[opt]
comment = opt
path = /opt/
read only = no
guest ok = yes

force user = root

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 28

DDWRT Wireguard setup guide by egc, last modified: 18-Jan-23 page 29