OpenWrt Forum Archive

Topic: OpenVPN Setup Guide

The content of this topic has been archived on 11 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I've rewritten the wiki OpenVPN setup guide to (hopefully) be both easier to follow and cover a much broader array of configurations.

I can't direct link to it (forum permissions), but it's the wiki page located at: /doc/howto/vpn.openvpn

The previous guide had many sections that appeared to have been written for running a TUN based server, but then had instructions for server bridging or running a client configuration haphazardly and incompletely (and in some places incorrectly!) scattered in. I've attempted to remedy this issue by writing it for the three most common configuration types (server, server-bridge, client)

I've also attempted to have the guide give a nearly-complete setup guide, hopefully removing (or at least greatly reducing the need for) "recipe" wiki pages.

However after staring at this for the last 4 days, I'm afraid there might be something I've overlooked. Let me know what you think.

I'd also greatly appreciate it if someone could try to follow the guide step by step and make sure everything works. After looking at something for so long, it's too easy to think that I wrote something, but switch it during actual execution without thinking about it. That and I'm kind of sick of looking openvpn in general right now.

Thoughts? Feedback?

Outstanding work!

I can only speak about the client part -- I think it would be beneficial to mention the luci-app-openvpn and that besides fully uci-ing openvpn settings or dropping the config file into /etc/openvpn/ you can also create uci (and luci app) friendlier tiny config by specifying the conf-file to use in it.

Also for the client configs where the login/password authentication is required would be great to mention that you'd normally create a text file and refer to it from the settings/ovpn/conf.

Bravo! I followed your guide (while it was being edited big_smile) and successfully set up a TUN server (TAP didn't work for me but I might have made some mistakes).

Feedback:
1) This is a minor thing, but in the "Test the tunnel" section you should mention, before anything else, how the clients are supposed to connect to the server (e.g. with the command "openvpn /path/to/conf/file" in linux)
2) You could mention how to push nameservers to the clients to avoid DNS leaks (if the server is used to access the Internet)
3) How about a client+server setup on the same router? Since the client and server guides are already there, you would only need to add a new section describing the routing policies that are necessary for this to work. I'm actually setting this up right now (https://forum.openwrt.org/viewtopic.php?id=68788) and I've got it working, but I'm still struggling a bit with the routing policies.

I made some changes:

  • Added some bits about using .conf files

  • Added the bit about user/pass files

  • Rewrote a significant chunk of the testing and route sections.

  • Fixed various typos or errors.

I'm going to avoid writing a guide on how to setup a client to connect to the server, since that will be highly platform specific. I refer users to consult the manual/documentation for their client.

I think I'm also going to avoid the DNS server issue. This is, by it's nature, a pretty basic guide. And pushing DNS servers contains a lot of OS-specific shenanigans on the client side of things. It's also generally just not a very useful thing aside from those looking for the strictest of security. People who require that level of security probably don't need a beginners guide, and could certainly figure out how to fill in the gaps.

Multiple OpenVPN instances is something I might address in a later revision, but probably just as a footnote somewhere with some generalized tips rather than full-on instructions. It's too use-case specific to really write a catch-all instruction set for.

(Last edited by ExaltedVanguard on 3 Dec 2016, 23:56)

I am getting the following error, when trying to execute step 2 of "Configure the network on the OpenWrt router."

uci: Invalid argument.

All of these commands, from that step, are returning the same error:

uci set firewall.Allow-OpenVPN-Inbound=rule
uci set firewall.Allow-OpenVPN-Inbound.target=ACCEPT
uci set firewall.Allow-OpenVPN-Inbound.src=*
uci set firewall.Allow-OpenVPN-Inbound.proto=udp
uci set firewall.Allow-OpenVPN-Inbound.dest_port=1194

What am I doing wrong?

(CC 15.05.1, r48532)

(Last edited by gcdavison on 4 Dec 2016, 12:47)

Oh whoops. Those should be underscores rather than hyphens. I'll fix it in the guide.

uci set firewall.Allow_OpenVPN_Inbound=rule

You're right about DNS, I found out that right now only Windows clients natively accept the pushed nameservers. But on the server side this is as simple as

push "dhcp-option DNS <primary nameserver address>"
[push "dhcp-option DNS <secondary nameserver address>]"

so. I don't know. it could be worth mentioning.

(Last edited by endvour on 6 Dec 2016, 00:59)

I finally got my server+client setup working! If you ever decide to describe this kind of setup in the wiki I'm happy to help with any clarification, although what I wrote in the General Discussion forum should be pretty straight forward. I could even write a little section myself and pass it to you for revision if you want me to.

endvour wrote:

You're right about DNS, I found out that right now only Windows clients natively accept the pushed nameservers.

I was wrong about this, that was probably outdated info. Pushing nameservers seems to work out of the box with Linux clients (I'm testing with Ubuntu 16.10). All that's necessary is pushing dhcp-option DNS and, if you want to use dnsmasq as the nameserver, set localservice 0 in /etc/config/dhcp (required if the VPN server interface uses unmanaged protocol). That's it! I'm able to reach devices in my LAN by hostname and outbound queries are correctly forwarded to my dnsmasq resolvers.
Again, happy to write a couple lines myself about this for the wiki.

UPDATE: works like a charm also with an Android 7.1 client using the OpenVPN for Android app

(Last edited by endvour on 15 Dec 2016, 02:42)

Hi!

Thanks for your guide!

I am confused though because there is another wiki that states that easy-rsa should not be used.

Easy-RSA does not create secure enough certs & has too many limitations, therefore OpenSSL should be utilized directly via an openssl.cnf

doc/howto/openvpn-streamlined-server-setup

However this 'steamlined' wiki doesn't work anyway, see viewtopic.php?id=68520

Should I just ignore the easy-rsa warning and follow the "OpenVPN Setup Guide for Beginners"?

Easy-RSA is plenty secure for normal users.

It probably wouldn't be the best choice if you're talking about a multi billion dollar corporation that has people and/or governments attempting to hack their way in. One would question why they didn't hire a security expert or why their security expert is reading a wiki setup guide rather than knowing what to do based off the man pages...

I also find it funny that that guide is using the openvpn machine as the CA machine. That is, the "master keys" are kept on the same machine as the openvpn server. If you're as security crazy as that guide is supposed to be, you'd think he'd advise against that.

But we don't worry about that for normal users. We just use Easy-RSA on the same machine because OpenVPN has been the "standard" for long enough that it's basic settings are more than adequate for the vast majority of use cases. It's been tested time and time again and if there were some massive glaring flaw it would have been fixed by now.

endvour wrote:
endvour wrote:

You're right about DNS, I found out that right now only Windows clients natively accept the pushed nameservers.

I was wrong about this, that was probably outdated info. Pushing nameservers seems to work out of the box with Linux clients (I'm testing with Ubuntu 16.10). All that's necessary is pushing dhcp-option DNS and, if you want to use dnsmasq as the nameserver, set localservice 0 in /etc/config/dhcp (required if the VPN server interface uses unmanaged protocol). That's it! I'm able to reach devices in my LAN by hostname and outbound queries are correctly forwarded to my dnsmasq resolvers.
Again, happy to write a couple lines myself about this for the wiki.

UPDATE: works like a charm also with an Android 7.1 client using the OpenVPN for Android app

Some distributions work well, others not so much. The biggest issue is laptops running various linux distributions. OpenVPN handles DNS (in some linux distributions) by saving the DNS servers on change, then restoring those settings on disconnect. On a laptop that might be migrating between connections, this can potentially lead to the wrong DNS servers being restored, compromising connectivity.

I wrote the guide with the idea that it will set up a VPN server with basic functions and connectivity for beginners, which can also be modified to meet specific use cases by advanced users who should know to read man pages.

With that in mind, I didn't feel the need to include DNS pushing because it is not a requirement of basic functions or connectivity, and 99% of users do not require this feature. It didn't make sense to include it in a beginner's guide where it will just generate more questions and confusion. Especially when such a feature is associated with so many client-specific variables that can potentially disrupt connectivity on client machines.

If you disagree with my assessment, you can certainly add it to the guide. It's a wiki and open for anyone to edit! That's the wonderful thing about open systems like wikis.

---

Even with an "optional" tag, every newbie around would attempt to use the feature because it "sounds" like it enhances security, but in the majority of cases just impairs performance with no added benefit. There is nothing illegal about a user looking up the IP (via DNS) of (for example) a torrent website, and an ISP won't throttle your connection for checking the domain. That could happen with browser prefetching and you reading a news article that mentions it. It's the actions after that which matter and will get your throttled (or arrested...) - and those are all done via the VPN.

If you're in a situation that merely looking up a domain name would get you into hot water... Well either 1) you're under an extremely oppressive government and you need a whole lot of fire-walling and such that's WAY outside the scope of any beginners guide (and you should sure as shit know your stuff because any mistake means you're fucked). Or 2) you're looking up some sort of honeypot domain that's only mentioned in one or two places on the net so what the fucking hell were you looking up? I'm not sure I want to help that person... although chances are they already know their shit anyway.

---

An alternative (which I'd totally agree with, but currently have no motivation to create) would be an "advanced customization of OpenVPN" -guide that was linked to at the end of the beginners guide. The explanation of DNS pushing and other features would be plenty appropriate in such a location. I wonder about the utility of such a guide though, since the users who would need such features are likely able to interpret the relevant manuals directly and probably don't need a step by step guide.

Very nice write up! Maybe something on split tunneling rules for users who want to run a client, but only for specific ip's?

Thanks for your detailed reply!
I went ahead and set up the VPN as per your instructions.

Having some issues with the routing tables.  Will try a few more things myself and will report back

cybrnook2002 wrote:

Very nice write up! Maybe something on split tunneling rules for users who want to run a client, but only for specific ip's?

I thought of creating this as a separate wiki page for exactly this but just haven't found the time or motivation. I actually did exactly this so that I could use a VPN for a non-rooted Amazon Fire TV.

Here's the short version:
1) Use route-nopull so the client doesn't affect other devices on the network.
2) Give device(s) in question a static IP
3) Create a new routing table.
4) Edit rc.local and use ip rule to make the device(s) use that routing table

ip rule add from 192.168.32.50 priority 10 table vpn

5) (optional) Add a firewall rule to prevent the device(s) from using your standard interface
6) Use an openvpn route-up script that calls ip tables to replace the default route of your new table with the VPN tunnel

ip route replace default via $ifconfig_remote dev tunUS table vpn
ip route flush cache

----

For my uses, I didn't want the fire TV attempting to use the normal WAN interface so that:
1) I could easily know when it's not connected via the VPN
2) I could prevent it from contacting servers from an inappropriate IP, so that I wouldn't be auto-logged out of stuff if my tunnel dropped. Typing in passwords on that thing is a PITA.

So in my case, there is never a connection coming into the fire from a different external interface.

If you have a device that you'll want primarily using the VPN gateway, but still want it to be able to receive connections from WAN (for example a torrent box with a web-control interface), you'll need to add some connection tracking rules to ensure that traffic is routed properly or you'll be dealing with a problem known as asymmetric routing. Briefly, you'll need to mark new connections coming in on the WAN interface and send those to the normal routing table. This is pretty advanced crap and is pushing the limits of what I know, so I won't be able to help you too much there, sorry.

(Last edited by ExaltedVanguard on 21 Dec 2016, 22:17)

ExaltedVanguard wrote:
cybrnook2002 wrote:

Very nice write up! Maybe something on split tunneling rules for users who want to run a client, but only for specific ip's?

I thought of creating this as a separate wiki page for exactly this but just haven't found the time or motivation. I actually did exactly this so that I could use a VPN for a non-rooted Amazon Fire TV.

Here's the short version:
1) Use route-nopull so the client doesn't affect other devices on the network.
2) Give device(s) in question a static IP
3) Create a new routing table.
4) Edit rc.local and use ip rule to make the device(s) use that routing table

ip rule add from 192.168.32.50 priority 10 table vpn

5) (optional) Add a firewall rule to prevent the device(s) from using your standard interface
6) Use an openvpn route-up script that calls ip tables to replace the default route of your new table with the VPN tunnel

ip route replace default via $ifconfig_remote dev tunUS table vpn
ip route flush cache

----

For my uses, I didn't want the fire TV attempting to use the normal WAN interface so that:
1) I could easily know when it's not connected via the VPN
2) I could prevent it from contacting servers from an inappropriate IP, so that I wouldn't be auto-logged out of stuff if my tunnel dropped. Typing in passwords on that thing is a PITA.

So in my case, there is never a connection coming into the fire from a different interface.

If you have a device that you'll want primarily using the VPN gateway, but still want it to be able to receive connections from WAN (for example a torrent box with a web-control interface), you'll need to add some connection tracking rules to ensure that traffic is routed properly or you'll be dealing with a problem known as asymmetric routing. Briefly, you'll need to mark new connections coming in on the WAN interface and send those to the normal routing table. This is pretty advanced crap and is pushing the limits of what I know, so I won't be able to help you too much there, sorry.

Oh man it would be awesome to have a detailed page for this :-) I can see you have explained it quite well in your summary here. Unfortunately firewall rules are still the art of black magic to me. I am learning as I go, but far from proficient enough to be able to read your summary while saying "Ah ha" and "Mm Hmm". More "Hmmmmm" and Mmmmmm" :-)

I think we are on the same page however. Yes, I have a few firesticks on my own in the house that I would like to ONLY be on the VPN. While the remaining devices on my network route through the normal WAN interface at full speed.

(Last edited by cybrnook2002 on 21 Dec 2016, 22:20)

Hah, And I think the firewall's the easiest part!

Just add the following to /etc/config/firewall (with the relevant IP, of course)

config rule
        option name 'VPNBlock'
        option src_ip '192.168.32.50'
        option dest 'wan'
        option target 'REJECT'

I have become stuck now with IP rules / forwarding I think

Details
VPN Server hosted on IP 192.168.0.126:1194 on a LEDE cisco MR12
Wifi is disabled. Only one Ethernet connection to the device. (192.168.0.0 255.255.255.0)
VPN Server is 10.1.0.0 255.255.255.240

Two interfaces on host
Name = VPN
Interface = VPN0 (virtual interface as made in wiki)

Name = LAN
Interface = br-lan (But I can also see that there is a eth0 with ifconfig command but it has no assigned IP)

WAN is out via 192.168.0.1 on my separate router

I have set my router IP Table so I am able to ping 10.1.0.1 from my pc 192.168.0.22
I connect from my remote device to the vpn fine with no errors in the logs but get not response from ping to 10.1.0.1 or 192.168.0.1 networks. I think I have something basic set wrong but can't figure it out.

I have uploaded a copy of my firewall, openvpn client and server settings to pastebin.
pastebin.com/X9nWAWUu

If anyone has  moment to check what I have wrong it would be most appreciated.

Found the error. Authentication was set to SHA512 on the client config  and the server wasn't. The error was not showing on my Android openvpn log but was visible on the Mac client.

The discussion might have continued from here.