[Pandora-Box]

Hi to All,
HAPPY HOLIDAYS to All!
FYI to all interested:
(And my apologies for such a lengthy post).
I would like to share my WireGuard and dd-wrt Kong build "holidays adventures", which ultimately fruitfully lead to a successful working setup.
I have tested it with Kong r38100M build on Netgear R7000 router.
I have predominantly (but not entirely) based my research and approach, with dd-wrt Kong's build and WireGuard setup, posted by Shinzu at:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=312522&postdays=0&postorder=asc&start=30
Great Work and Thank You Shinzu!

BIG Note: my goal was to get VPN running and operational connecting to Internet, and NOT so much security guards as of DNS leaks or any KillSwitches (they are not the scope of this document)

And now to the entire environment and settings:

WireGuard SERVER setup (running somewhere very remotely on the planet Earth):
VirtualBox Ubuntu 18.04.1 64 bit Desktop VM on Windows 10 Pro on a laptop.
WireGuard setup was closely followed and based on: https://www.ckn.io/blog/2017/11/14/wireguard-vpn-typical-setup/
Just a few tweaks to get it running and working suiting my needs to access Internet remotely using WireGuard VPN tunnel.
Remote SERVER WireGuard config file:
___________________________
[Interface]
Address = 10.XXX.YYY.Z/24
MTU = 1500 #AUTO (default 1420 value not supported with number of services; tested other values to no avail)
SaveConfig = false (can be set up to true, it will overwrite config file)
PrivateKey = PrivateKey
ListenPort = server listening port (default 51820)

# note - substitute ethX in the following lines to match the Internet-facing interface
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ethX -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ethX -j MASQUERADE

# Peer 1
[Peer]
PublicKey = PublicKey
AllowedIPs = 10.XXX.YYY.A/32, 192.168.0.0/16 (192. sub needed for home networks)

# Peer 2-dd-wrt router
[Peer]
PublicKey = PublicKey (this value somehow was generated by dd-wrt itself (no clue how; maybe when testing WG on BS build)
AllowedIPs = 10.XXX.YYY.B/32, 192.168.0.0/16 (192. sub needed for home networks)
___________________________
NOTE: the wg0 interface references can and should be swapped with `%i` as the config is dependent on the filename with the setup (in the config PostUp and PostDown); It is working this way

Server WG startup script:
___________________________
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 51820 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 10.XXX.0.0/16 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 10.XXX.0.0/16 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.XXX.0.0/16 -o ethX -j MASQUERADE
sysctl -p
wg-quick up wg0
exit

NOTES:
--dport 51820 server listening port (default 51820)
10.XXX.0.0/16 this is entire 10.XXX sub, could be changed to a smaller or different subnet
ethX refers to WAN facing server interface (not WG interface)
These above iptables rules were taken from various internet sources and adjusted accordingly to get things working
END of SERVER SETUP
_______________________
WireGuard CLIENTS:
One client running on Ubuntu 18.04.1 64 bit Desktop physical machine (not VM), just to aid testing with dd-wrt setup
wg-quick wg0 setup pretty much default;
only MTU = 1500 #AUTO (default 1420 value not supported with number of services; tested other values to no avail)
and it worked as is, with the above server
_______________________
DD-WRT setup:
_______________________
dd-wrt was a bit more complicated but doable:
dd-wrt was set up as a client to the above server (I did not want dd-wrt as a WG server!)
Here I followed Shinzu's guide (link above):
-got firmware-mod-kit
-got latest BS dd-wrt build 12-26-2018 r38104 for netgear-r7000-webflash
-Extracted Shinzu's indicated files and placed on /opt volume, since I do have opkg installed, in respective directories as indicated by Shinzu.
I changed all these files permissions to 755, since I was not sure what exactly permissions they should have set.
I modified Shinzu's nvram script and included only those variable which showed up when I did install BS build to check BS WG settings.
Number of Shinzu indicated nvram variables do NOT take effect anyway, they just only take much needed nvram free space:

My NVRAM script:
___________________
#!/bin/sh
#
echo "Write variables"

# number of tunnel my case only 1
nvram set oet_tunnels="1"
# if you want to use a preshared key set 1
nvram set oet1_usepsk0="0"
# remote endpoint's WAN IP address; or DNS name
nvram set oet1_rem0="remote WAN WG server IP address or DNS name"
nvram set oet1_rem="192.168.90.1"
# public key of local (Client) endpoint
nvram set oet1_public="<public key of local (Client) endpoint; dd-wrt; somehow it generated itself; no clue how>"
# set here the pre shared key if you want to use one
nvram set oet1_psk0=""
# proto 2 is wireguard
nvram set oet1_proto="2"
# private key of local endpoint
nvram set oet1_private="<private key of local endpoint; dd-wrt; somehow it generated itself; no clue how>"
# public port where wireguard tunnel is reachable
nvram set oet1_port="<LEFT EMPTY INTENTIONALLY, SINCE WG CLIENT DOES NOT NEED LISTENING PORT DEFINED>"
# number of peers
nvram set oet1_peers="1"
nvram set oet1_peerport0="51820" # This is default port; use port remote WG server is listening on
# this is Peer (Server) Public Key
nvram set oet1_peerkey0="<Peer (Server) Public Key>"
# netmask of the wireguard network (can be adjusted accordingly)
nvram set oet1_netmask="255.255.255.0"
nvram set oet1_local="0.0.0.0"
# Value below is for persistent keepalive, can be 21 or 25 sec
nvram set oet1_ka0="21"
# WG tunnel ip address of the endpoint of the dd-wrt device; use the same subnet as WG server; eg server 10.10.10.1 client 10.10.10.2, or so
nvram set oet1_ipaddr="10.XXX.YYY.B"
nvram set oet1_id="1"
nvram set oet1_endpoint0="1"
# for now leave the tunnel disabled
nvram set oet1_en="0"
# set bridge to 0 otherwise the iptables rules are not added
nvram set oet1_bridged="0"
# Value below is for Allowed IPs; client setup
nvram set oet1_aip0="0.0.0.0/0"

# Commit variables
echo "Save variables to nvram"
nvram commit
_______________________
Any other nvram values indicated by Shinzu were omitted; if included, I could not connect to WG server or to Internet using WG tunnel; it is so many variables that could affect WG connectivity

Next I did have to modify eop-tunnel.startup script; since I had lots of connectivity problems:
I did remove promiscuous WG interface setting (not sure why it is defined as promisc in the original script)
so removed "promisc" from ifconfig part, and replaced with txqueuelen 1000; since original "1" seemed very different than all other interfaces exhibited; I also could not established WG connection
I also added mtu setting 1500 since I had problems before with the default 1420 value
ORIG script:
>>>done
ifconfig oet${i} promisc up 2>&1 > /dev/null
ip addr add $($nv get oet${i}_ipaddr)/$(getmask $($nv get oet${i}_netmask)) dev oet${i} 2>&1 > /dev/null
echo enable > ${i}.pid<<<
MODIFIED part of the script:
>>>done
ip link set mtu 1500 dev oet${i}
ifconfig oet${i} txqueuelen 1000 up 2>&1 > /dev/null
ip addr add $($nv get oet${i}_ipaddr)/$(getmask $($nv get oet${i}_netmask)) dev oet${i} 2>&1 > /dev/null
echo enable > ${i}.pid<<<
I did save this script in /opt/etc/config/eop-tunnel.startup file location

And now a moment of truth connecting to WG server and establishing tunnel VPN and Internet connectivity.
It took lots of trials, adjustments and fiddling, but finally I succeeded (especially that it was done on home "production" router; THX to patient family members.
I had to manually add proper routes and ip rules to get it working and to suit my needs:

ip route add <WG server remote WAN IP address> via <my ISP provided subnet gateway> dev vlan2
ip route add <WG server subnet> via <WG server tunnel endpoint IP address (10.XXX.YYY.A)> dev oet1
ip route add 0.0.0.0/1 via 10.XXX.YYY.A dev oet1
ip route add 128.0.0.0/1 via 10.XXX.YYY.A dev oet1
these two letter routes 0.0.0.0/1 and 128.0.0.0/1 take routing precedence over default route 0.0.0.0/0
I also added a small script to accommodate guest and multiple home subnets:
______________________
#!/bin/sh
ip rule add from 192.168.AAA.0/24 table 100
ip route add default via <my ISP provided subnet gateway> dev vlan2 table 100 #ISP Gateway
ip route add <ISP LAN> dev vlan2 scope link src <dd-wrt IP from ISP> table 100 #ISP LAN
ip route add 192.168.BBB.0/24 dev br0 scope link src 192.168.BBB.1 table 100 #My LAN B
ip route add 192.168.CCC.0/24 dev br1 scope link src 192.168.CCC.1 table 100 #My LAN C
ip route add 192.168.DDD.0/24 dev br2 scope link src 192.168.DDD.1 table 100 #My LAN D
# Optional routes from my router:
# 10.0.111.0/24 via 192.168.EEE.xxx dev br0
# 10.1.222.0/24 via 192.168.FFF.yyy dev br0
ip route flush cache # force routing system to recognize the changes
Routes in main routing table are using WG VPN tunnel
Routes in table 100 are connecting directly through ISP (and not WG VPN tunnel)

And finally at the end of your WG session do not forget down oet1 interface and reset nvram:
ip link delete dev oet1
nvram set oet1_en="0"

I hope this will help a bit and save some time establishing WG connectivity; IT IS WORTH IT!
Any constructive suggestions will be very gladly welcomed.
Thanks.
Good Luck
P-B

[ersterhernd]

Thanks for the detailed post P-B. I will do the same after compiling all of my steps. WG running flawlessly at server on a Vultr instance and client end on R7000 and RT-AC68U.

Should I include the required binaries attached to my post or would that violate forum rules? I'm a newbie here and dont want to lose posting privileges.


Cheers

Ersterhernd

[Pandora-Box]

@Ersterhernd
I am really glad you found your answers in this forum, and got working WG setup.
Congrats!
Regarding "binaries", I am not sure what are you referring to.
If to previously mentioned files required for Kong's builds to run WG, NO, you do not need to attach them, there is a procedure described in great detail how to get them.
You can just post your settings or scripts if they are very different from those posted previously, and you think they will assist and help other dd-wrt and WG users.
Sincerely,
P-B

[ersterhernd]

I have created a separate thread to share my information on this subject.

https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1152435#1152435

Cheers!
Ersterhernd