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. _________________ AC-68U rev. C1 on Build 45420
AC-68U rev. A1 on Build 45493
AC-68U rev. A1 on Build 44340
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.
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.
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/1 on Archer C9
Posted: Thu May 24, 2018 9:20 Post subject: WireGuard Routing
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:
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.
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 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.
You *could* just create a startup script which killed the current OpenVPN process from the GUI, wait for internet access (ping 18.104.22.168 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?
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.
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.
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
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
Posted: Thu Jul 19, 2018 14:12 Post subject: Be aware of WireGuard limits
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