WireGuard

Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT Forum Index -> Advanced Networking
Goto page Previous  1, 2, 3, 4  Next
Author Message
Sash
DD-WRT Guru


Joined: 20 Sep 2006
Posts: 17619
Location: Hesse/Germany

PostPosted: Wed Mar 07, 2018 23:55    Post subject: Reply with quote
i'm working on: wiki

but i'm not happy with the current implementation

see svn tickets: 1 2 3 4

_________________
Forum Guidelines...How to get help
&
Forum Rules
&
RTFM/STFW
&
Throw some buzzwords into the WIKI search Exclamation
_________________
I'm NOT rude, just offer pure facts!
_________________
Atheros (TP-Link & Clones, etc ) debrick service in EU
_________________
Guide on HowTo be Safe, Secure and Protect Your Online Anonymity!
Sponsor
wabe
DD-WRT Guru


Joined: 17 Jun 2006
Posts: 889

PostPosted: Thu Mar 08, 2018 13:57    Post subject: Reply with quote
Sash wrote:
i'm working on: wiki

but i'm not happy with the current implementation

see svn tickets: 1 2 3 4


Great! Look forward to the wiki post. Good suggestions on improvements. Would also be nice to enable setup of a custom configuration and run it from a script.

_________________
Netgear R7000 on Build 55109
Asus AC-AC68U rev. C1 (AP) on Build 55109
Asus AC-68U rev. A1 on Build 54604
Asus AC-68U rev. A1 on Build 53339
popoviciri
DD-WRT Novice


Joined: 27 May 2017
Posts: 12

PostPosted: Thu Mar 22, 2018 6:51    Post subject: Reply with quote
Did any of you manage to set it up? I tried Mullvad’s wireguard config derived from their howto for lede, but no joy. I believe I’m getting stuck at configuring the firewall. Iptables are still a big mistery to me. Please post details, should any of you made some progress on the topic.
Thanks!!
Sash
DD-WRT Guru


Joined: 20 Sep 2006
Posts: 17619
Location: Hesse/Germany

PostPosted: Thu Mar 22, 2018 9:11    Post subject: Reply with quote
in any case you will have to add firewall rules to successfully communicate through the tunnel on each unit.

eg:
Code:
#for reaching the unit in/out
iptables -I INPUT -i oet1 -j ACCEPT
iptables -I OUTPUT -o oet1 -j ACCEPT
#for forwarding packets to the networks behind in/out
iptables -I FORWARD -i oet1 -j ACCEPT
iptables -I FORWARD -o oet1 -j ACCEPT


also you have to set routes for the networks to reach

eg:
Code:
#to connect 192.168.1.0/24 and 192.168.2.0/24 via 10.10.10.2 put on the 192.168.1.0 gateway
route add -net 192.168.2.0/24 gw 10.10.10.2
#etc


update: atm i'm investigating why the rules are not set automaticly

_________________
Forum Guidelines...How to get help
&
Forum Rules
&
RTFM/STFW
&
Throw some buzzwords into the WIKI search Exclamation
_________________
I'm NOT rude, just offer pure facts!
_________________
Atheros (TP-Link & Clones, etc ) debrick service in EU
_________________
Guide on HowTo be Safe, Secure and Protect Your Online Anonymity!
xecutioner
DD-WRT Novice


Joined: 16 Apr 2018
Posts: 1

PostPosted: Mon Apr 16, 2018 17:04    Post subject: Reply with quote
I setup the firewall rules as you mentioned, but traffic is still not going through oet1. in the route command is the first ip the ip of the wireguard server we are trying to reach? When I do a route command on the router, it shows oet1 as a line, but then always goes through my ISP gateway regardless of the gateway indicated. I get network unreachable when I use the route command with the VPN ip and VPN gateway server.
The LT
DD-WRT Novice


Joined: 02 May 2018
Posts: 4

PostPosted: Wed May 02, 2018 22:27    Post subject: Reply with quote
I've played with wireguard for a while and something is definately wrong with it at the moment.

Even if I clear all rules and chains, it fails to initiate peer connections. I can force other peers to initiate connections with dd-wrt machine, but it's very intermittent and it takes a few reboots and pings to get it going.

Even if I manage to get it going and have all the routes setup between peers, things get even more weird.

I can ping both subnets for some time. But when I try to initiate connections from the hosts behind NAT through wireguard, dd-wrt box crashes and reboots.

It also seems to crash even after a couple dozen of forwarded ICMP packets. If I ping the peer interface address itself, it works fine.

Running Firmware: DD-WRT v3.0-r35831 std (04/26/1Cool on Archer C9
The LT
DD-WRT Novice


Joined: 02 May 2018
Posts: 4

PostPosted: Mon May 07, 2018 11:02    Post subject: Reply with quote
Interestingly enough, the router doesn't crash if I try to access whatever is behind it from outside.
BrassyPanache
DD-WRT Novice


Joined: 24 May 2018
Posts: 2

PostPosted: Thu May 24, 2018 9:20    Post subject: WireGuard Routing Reply with quote
TL;DR; I had a great experience setting up WireGuard. It was a breath of fresh air compared with OpenVPN. There are a few rough edges, but it's extremely promising.


I have two sites which both have Archer C9 v2 devices installed. They are flashed with build v3.0-r35927. My aim is to have the private address spaces of the two networks bidirectionally reachable over a secure public link. It seems as though the OpenVPN router (TUN) will allow me to have this set up. I have had a lot of difficulty establishing a reliable link due to:

    - The OpenVPN configuration takes research! The certificate and key generation is not clearly documented, and there are many variations. On top of this OpenVPN has many legacy options. This makes configuration overly complex with a huge number of possible combinations. To me this feels dangerous as cryptography is a complex field; I cannot honestly say if my running setup is secure due to my lack of in-depth knowledge.

    - Once you have a working OpenVPN configuration the routing feels as though it deviates from the regular Linux toolset. The asymmetry of the configuration (having a server and client) also adds complexity. You need to exclude certain clients from receiving pushed routing with the ignore route command using client specific configuration.

    - Once you've worked through all of this, DD-WRT adds additional complexity with the need to mount a JFFS for persistent client configuration.

    - Finally, and the deal breaker for me, was the long running issues (https://svn.dd-wrt.com/ticket/5807) with ebtables. I believe I've narrowed this down to the client OpenVPN connection trying to initialise before the WAN link is up. Thus the router doesn't have an NTP provided time and as such the keys and certificates cannot be validated. The outcome basically means that the client side of the link will not automatically connect on a fresh boot and be left with an ebtables process spinning on a core of the router. To make the connection you need to manually connect to the router, disable, and then re-enable the OpenVPN connection.

If anyone is having the issues I have described above I can recommend they take a look at WireGuard. For me the great points:

    - Key generation is super simple and supported with the tools provided.
    - The routing is as would be expected for a Linux environment. I can simply add routes as I would with any other interface.
    - The configuration is symmetric which feels much more comfortable to me.

And some future improvements I hope can be made:

    - I needed to use the command-line to add additional allowed-ips. It didn't work without having both the remote link address and the private network address space listed. I needed the command-line because the web based interface doesn't allow comma separated entries due to the input text box being limited to 18 characters. Something like "10.0.0.1/32,192.168.1.0/24" should be allowed.

    - On the establishment of a connection it would be great if the static routes could be inferred from the allowed-ips and added automatically. As an example the above would result in:

    Code:
    route add -net 192.168.1.0/24 gw 10.0.0.1

    Even if they're not automatically added, at least if they can be specified on the web configuration that would be amazing.

Overall it's shaping up really well. I'm very excited that we may soon be free from horribly complex OpenVPN configurations.
The LT
DD-WRT Novice


Joined: 02 May 2018
Posts: 4

PostPosted: Sat May 26, 2018 10:37    Post subject: Reply with quote
My C9 is still crashing on latest beta 36006. I narrowed it down to NAT traffic. When the routers send direct traffic between wireguard oet interfaces, it's fine. When a DD-WRT box tries to NAT traffic to a remote wireguard endpoint, it crashes. It doesn't crash when a remote wireguard endpoint contacts one of the internal addresses.

Not sure how to debug this.
The LT
DD-WRT Novice


Joined: 02 May 2018
Posts: 4

PostPosted: Tue May 29, 2018 16:27    Post subject: Reply with quote
I figured out SFE was what was crashing my C9 when using site-to-site WG. Disabling SFE solved it.
BrassyPanache
DD-WRT Novice


Joined: 24 May 2018
Posts: 2

PostPosted: Wed May 30, 2018 0:07    Post subject: Reply with quote
Hey eibgrad. Thanks for responding Smile

eibgrad wrote:
Not sure what you're referring to in terms of the need for JFFS. Unless you're running the OpenVPN client from the command line rather than the GUI. And even so, it is possible to store your own variables in nvram, or recreate files using the startup script. Regardless, this isn't an OpenVPN issue. It would affect anything requiring external storage, including Wireguard. Or else I'm misunderstanding your point.


I found I had to mount JFFS to have a persisted Client Configuration Directory. This enables you to push specific ignore routes (iroute) to clients based on a match with the public key common-name (see: https://community.openvpn.net/openvpn/wiki/RoutedLans). Not sure if this was the best way forward, but with multiple clients and the desire for them all to be connected it was the only solution I came across.

eibgrad wrote:
You *could* just create a startup script which killed the current OpenVPN process from the GUI, wait for internet access (ping 8.8.8.8 until you get a positive response), then restart the OpenVPN client.


I didn't investigate this option. Thanks for the suggestion. I guess it's similar to how the server side of OpenVPN allows you to start on WAN?

eibgrad wrote:
Overall, I do get your points about OpenVPN though. It tries to serve as many different ppl under as many varied situations as possible. And that invariably leads to complexity. OpenVPN is much more of a client/server sort of application too. While I don't know much about Wireguard, it *sounds* like it's more of a peer to peer application, similar to commercial products like Hamachi and ZeroTier.

Ironically, OpenVPN does offer a very simple configuration requiring just a few lines of code.

https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html

The problem, however, is that invariably users want more and more features, so that very simple, basic configuration is rarely considered, let alone offered.

Just doesn't get any simpler. The only thing you need to generate is the static key, and even that can be generated from the openvpn app itself. I've used this type of configuration myself from time to time (from the command line) when I wanted something quick and dirty.

I wouldn't be surprised to see Wireguard grow in complexity too. Most new things start out lean and mean, but eventually fall victim to feature creep (remember when Chrome and Firefox were considered the better alternatives for these reasons!).


I agree. Sadly often things which do their job well gain complexity as time goes.

Also, I'd never come across that static OpenVPN configuration before. At a quick read it offers similar simplicity to Wireguard. One of the bigger things is taking the complexity of the key management out for simple setups. That seems to fit the bill. Thanks for the pointer.

eibgrad wrote:
Anyway, I look forward to seeing what Wireguard has to offer. Like anything new, it hasn't truly been tested until it becomes more adopted and mainstream. You just never know what vulnerabilities it might have until something bad happens. So I'd be careful about being overly confident until it's had a chance to be exposed to the hacker community for a while. I can hear them rubbing their hands together in anticipation already.

Me too. So far so good, but it will be good to see the addition of the SVN tickets which Sash linked. So far my Wireguard connection has been running solidly since my prior post. And yes, I'm keeping my ear to the ground for security updates: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Wireguard Smile
liverpoolatnight
DD-WRT User


Joined: 29 May 2008
Posts: 243
Location: United Kingdom

PostPosted: Sun Jul 15, 2018 16:41    Post subject: Reply with quote
There is a missing module insmod ip_tunnel what BS has fixed with r36315 and also hes added a userspace logging for tunnel services in r36313

BrassyPanache wrote:
Finally, and the deal breaker for me, was the long running issues (https://svn.dd-wrt.com/ticket/5807) with ebtables.


see r36333 this maybe a fix for you.

BrassyPanache wrote:
I needed to use the command-line to add additional allowed-ips. It didn't work without having both the remote link address and the private network address space listed. I needed the command-line because the web based interface doesn't allow comma separated entries due to the input text box being limited to 18 characters. Something like "10.0.0.1/32,192.168.1.0/24" should be allowed

Normally in Linux OS's WG configs it needs to be like
Code:
Address = 10.0.0.1/32, 192.168.1.0/24


add option to set a DNS in GUI

Tryed build 07-16-2018-r36330 however comparing this between openwrt and dd-wrt, By default dd-wrt is missing the endpoint IP 1.2.3.4 and a UGH flag inside route (using 1.2.3.4 as an example)

Code:
root@router2:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 VPN
10.20.0.0       *               255.255.224.0   U     0      0        0 VPN
1.2.3.4         192.168.1.1     255.255.255.255 UGH   0      0        0 br-WAN
192.168.1.0     *               255.255.255.0   U     0      0        0 br-WAN
192.168.8.0     *               255.255.255.0   U     0      0        0 br-lan

192.168.1.1 will be your WAN IP as im double NATed

Quote:


mullvad iptables found in there config file.

##PostUp
iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

##PreDown
iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

_________________
TP-Link TL-WDR3600 v1 [EU]: r36330 (07/16/18 )
D-Link DIR-615 D2 [EU]: r36330 (07/16/18 )
Mikrotik RB750r2 (OpenWrt 17.01.4)
EE BrightBox 1 aka A4001N (OpenWrt 17.01.4)
Sagemcom FAST@5364 (VDSL2,FTTC (Fibre to the Cabinet) Synced 65/17

Twitter: @francisuk1989
---------------------------------
Found a bug? Report it http://svn.dd-wrt.com
DD-WRT Official FB Group: https://www.facebook.com/groups/493762527744455


Last edited by liverpoolatnight on Thu Aug 09, 2018 15:16; edited 2 times in total
ice.man
DD-WRT Novice


Joined: 16 May 2013
Posts: 4

PostPosted: Thu Jul 19, 2018 14:12    Post subject: Be aware of WireGuard limits Reply with quote
I'm using Wireguard as a vpn server on a linux-VM nd I'm impresses of the tunnel creation speed and generl performance
Unfortunately I still need to rely on powerhungry OpenVPN as far as WireGuard only works on UDP
My experience is a very common firewall setup in public wifi (hotels, libraries, schools, university, etc) is to block all traffic but TCP port 80 and 443
this meaning desktop email clients will fail to work (no problem with webclients) but even wireguard is blocked (no matter if I set it to work on port 443)
So I actually have both of them up and running
Shinzu
DD-WRT Novice


Joined: 29 Jul 2018
Posts: 4

PostPosted: Sun Jul 29, 2018 13:59    Post subject: Reply with quote
Sash wrote:
...
update: atm i'm investigating why the rules are not set automaticly


maybe you found out already why the iptables rules not added, seems that oet<interface number>_bridged is set to 1 and because of that the iptables rules are not set

i set it via nvram set oet1_bridged=0 and the rules are added

see https://svn.dd-wrt.com/browser/src/router/eop-tunnel/eop-tunnel.firewall
liverpoolatnight
DD-WRT User


Joined: 29 May 2008
Posts: 243
Location: United Kingdom

PostPosted: Thu Aug 02, 2018 15:44    Post subject: Reply with quote
Shinzu wrote:
you found out already why the iptables rules not added, seems that oet<interface number>_bridged is set to 1 and because of that the iptables rules are not set
i set it via nvram set oet1_bridged=0 and the rules are added
see https://svn.dd-wrt.com/browser/src/router/eop-tunnel/eop-tunnel.firewall


Reported this here for you, Ticket 6391

_________________
TP-Link TL-WDR3600 v1 [EU]: r36330 (07/16/18 )
D-Link DIR-615 D2 [EU]: r36330 (07/16/18 )
Mikrotik RB750r2 (OpenWrt 17.01.4)
EE BrightBox 1 aka A4001N (OpenWrt 17.01.4)
Sagemcom FAST@5364 (VDSL2,FTTC (Fibre to the Cabinet) Synced 65/17

Twitter: @francisuk1989
---------------------------------
Found a bug? Report it http://svn.dd-wrt.com
DD-WRT Official FB Group: https://www.facebook.com/groups/493762527744455
Goto page Previous  1, 2, 3, 4  Next Display posts from previous:    Page 2 of 4
Post new topic   This topic is locked: you cannot edit posts or make replies.    DD-WRT 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