Build a Server VPN with openvpn - create c...
daveraver 14 Jan 2017
I want to share my experience creating a vpn server on openpli 4.0.
First of all, install openvpn
opkg install openvpn
Next, we will create files ca.crt, server.crt, server.key, same files for clients, client.crt, client.key, following this link (I've been guided to the link by littlesat, thanks):
https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide
I saw that doing openvpn --help on box command line, all files have to be .pem extension. Let's to convert the files:
Follow this guide:
https://blog.didiers...ssl-on-windows/
up to finish this three last steps:
set RANDFILE=c:\demo\.rnd set OPENSSL_CONF=C:\OpenSSL-Win32\bin\openssl.cfg c:\OpenSSL-Win32\bin\openssl.exe
Now, in this mode, you can convert .crt and .key files to .pem for server files, to put in stb at /etc/openvpn/
$ openssl> x509 -in filename.crt -inform DER -out filename.crt.pem -outform PEM $ openssl> rsa -in filename.key -out filename.key.pem -outform PEM
The ca.cert file, he have to open the certificate in windows OS and select details tab> copy file>convert to binary DER x509 and select destination folder to save.
Then we convert the ca.cer file to .pem file:
OpenSSL>x509 -inform DER -in ca.cer -outform PEM -out ca.pem
All these conversions to .pem extension is based on openvpn --help binnary information of our instalation of openvpn in our STB, maybe it's not necessary.
dh2048.pem have to locate at openvpn config directory too, /etc/openvpn
I add two extra .pem files to the directory 01.pem and 02.pem, they have been generated on the files creation, they contains key info, I dont know if there is duplicity of information.
Lets to put the server config file parameters /etc/openvpn/server.conf
local 192.168.xxx.xxx (local network IP) server 10.8.0.0 255.255.255.0 (for example) tls-server proto udp port 443 (sample port) dev tun ca ca.pem dh dh2048.pem cert server.crt.pem key server.key.pem extra-certs 01.pem extra-certs 02.pem ifconfig-pool-persist ipp.txt comp-lzo float ping-timer-rem persist-key persist-tun status openvpn-status.log log openvpn.log verb 3 keepalive 10 120
Client profile *.ovpn (tested on android openvpn app).
client dev tun proto udp remote 'hostname(NOIP) or Public IP' 443 (sample port) resolv-retry infinite nobind persist-key persist-tun mute-replay-warnings ca /file_path/ca.crt cert /file_path/client.crt key /file_path/client.key ns-cert-type server cipher bf-cbc comp-lzo verb 3 mute 20
The port we are going to use to vnp connection have to be opened, of course, and you can forward to other external different port as you know.
Happy VPN connection.
Erik Slagter 14 Jan 2017
There you go! I didn't check every byte of the config, but from a glance it looks correct. Now let's see how many people will find this tutorial. I hope many, of course.
athoik 14 Jan 2017
daveraver 14 Jan 2017
Don't forget to create a wiki page where users can update there: https://wiki.openpli.org/OpenVPN-Setup
Ok, thank you, I've finsihed the wiki page right now, if somebody want to edit it to do better design...cheers!
daveraver 14 Jan 2017
littlesat 14 Jan 2017
Thanks.... finally a guide is started...
Still I think the server.conf showed here is a bit extra complicated.... Why the extra certs.....
And with 10.8 you take a small risk.... check the list spacerat showed and pick a bit more strategic IP range for the 'tunnel'
e.g. 192.168.33..... or so....
Edited by littlesat, 14 January 2017 - 23:38.
daveraver 14 Jan 2017
In reference of extra certs files 01.pem 02.pem i dont know if they are productive, but I had it, and I put it, I dont know what utility have them. Do you know anything about this. we can be critic to improve, not to disturb. so tell us your opinion to make a right configuration, please. thank you.
Edited by daveraver, 14 January 2017 - 19:43.
SpaceRat 14 Jan 2017
192.168.1.x is bad too.Thanks.... finally a guide is started...
Still I think the server.conf showed here is a bit extra complicated.... Why the extra certs.....
And with 10.8 you take a small risk.... check the list spacerat showed and pick a bit more strategic IP range for the 'tunnel'
e.g. 192.168.1.33 or so....
Good choices:
172.16.x.y to 172.31.x.y
192.168.3.x to 192.168.9.x
192.168.11.x to 192.168.99.x
192.168.101.x to 192.168.177.x
192.168.181.x to 192.168.255.x
Neither the tunnel nor the local network should be one of the bad ones.
Why?
Because a lot of "alien" networks (WiFi hotspots, cellular networks, friend's networks) will be already.
Gesendet von meinem Siemens C25 mit Tapatalk
WanWizard 14 Jan 2017
A very good choice is 198.18.0.0/15.
It is not routed on the internet, but hardly anyone ever uses it.
172.16.0.0/12 is my preferred range, so rather not.
littlesat 14 Jan 2017
And to complete the thing... here an example for an ovpn file that can be used for openvpn on an iOs device... The xxx should be of course be replaced by the specific key stuff,... And note using port 443 is smart...
client dev tun proto tcp remote XXX.XXX.XXX.XXX 443 resolv-retry infinite nobind persist-key persist-tun ns-cert-type server comp-lzo <ca> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </cert> <key> -----BEGIN ENCRYPTED PRIVATE KEY----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END ENCRYPTED PRIVATE KEY----- </key>
Edited by littlesat, 14 January 2017 - 23:36.
littlesat 14 Jan 2017
192.168.1.x is bad too.
-> typo... I meant 192.168.33.xxxx
Edited by littlesat, 14 January 2017 - 23:39.
WanWizard 14 Jan 2017
I will try to consolidate this information in the next few days, and update/tidy the wiki entry...
SpaceRat 15 Jan 2017
Uhm, several tools use it to generate dead routes.A very good choice is 198.18.0.0/15.
It is not routed on the internet, but hardly anyone ever uses it.
The "adblock" extension on OpenWrt/LEDE makes DNSMasq resolve "bad hosts" to some IP in that range and then use DNAT for http/https to let the own busybox httpd answer requests to these bad hosts with 1px graphics.
And they have already changed the IP, because some other tool uses that address range too ...
Haha ... well ...172.16.0.0/12 is my preferred range, so rather not.
IPv4 is a major pain in the ass.
Even if one follows my hints about the network address ranges, there still will we other networks using the same or colliding address ranges.
It's just much less likely.
The bad thing is: You won't notice until it is too late.
Using 192.168.178.x for the home LAN will work perfectly nice ... until you really want to establish a VPN connection while being in a network of a Fritz!Box with default configuration.
And if you ever travel to Germany, that will be >50% of all home networks or other networks using plastic routers
Using 192.168.1.x at home would also work nicely, as long as you are trying to establish the VPN from default Fritz!Box networks or the Telefonica/o2 cellular network in Germany (Using 10/8) ... but will fail as soon as you arrive at a hotel which uses 192.168.1.x for its WiFi too ...
The Fritz!Box itself forces you to change that address range as soon as you configure its own VPN feature.
It's a shame that a lot of wide open OWIFs I found obviously are located inside Fritz!Box networks (As hardly any other router brand uses 192.168.178.x as default and lots of boxes I found had an address in that range).
Those users have an easy to use IPSec solution built into their routers and still open the OWIF directly to the net, without even setting a password
SpaceRat 15 Jan 2017
The same works for server configs too!And to complete the thing... here an example for an ovpn file that can be used for openvpn on an iOs device... The xxx should be of course be replaced by the specific key stuff,... And note using port 443 is smart...
... <ca> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- </cert> <key> -----BEGIN ENCRYPTED PRIVATE KEY----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END ENCRYPTED PRIVATE KEY----- </key>
Just add the DH params like this
<dh> -----BEGIN DH PARAMETERS----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END DH PARAMETERS----- </dh>I really like it that way, because that way you only got a single config file for the server rather than 5 for which the paths may break.
littlesat 15 Jan 2017
Edited by littlesat, 15 January 2017 - 10:55.
Erik Slagter 15 Jan 2017
"Class E" range, unless you have any windows stuff in your home, which they appear to refuse.
SpaceRat 15 Jan 2017
It (almost) does this already:Probably owif could be configured by default when a request does not come from the local network or the ip-address as configured in server.conf from openvpn that owif does not respond.... And when you u do this you get a big warning splash screen...
If you do not configure "auth" for OWIF, it will accept local connections only and refuse all others with reason 403.6 (IP address range not allowed).
If I'm not entirely wrong, (tun-)connections from OpenVPN road warriors will usually be MASQUERADEd to originate from the box OpenVPN is running on = local network too.
tap-connections are bridged, the client gets an IP from the local network address space too ...
Two quirks:
Even a lame auth like root:root will re-enable access from any IP and thus port-forwarded access again ... but we are not here to force people into their own luck.
As long as Dream doesn't implement similar counter-measures into their Dream WebControl, there are more thankful victims out there ("Not in my back yard" principle) and the basic idea was to just put a show stopper to port-forwarded access to make people start thinking why we could want them to do that.
So far the responses from forums prove me right, people come and ask how to re-enable access and we can suggest a VPN solution instead.
If they then use a VPN or just set a lame pass is beyond our control and what we should dictate (at the moment).
MASQUERADING requires another kernel module which might not be available on all boxes.
The advantage of the oe-a images is that we mirrored the vendor's bsps and thus can modify kernel configs as we deem fit, e.g. to implement iptables/ip6tables, masquerading, ...
OpenPLi uses and serves to the users whatever the box vendor deemed fit.
My To-Do list is clear:
1. Finish simple-rsa
2. Implement whatever is required to make OpenVPN VPNs work smoothly on the box for real VPNs with the emphasis on P as in Private (in contrast to "privacy" providers that are just (ab)using the term VPN).
3. Implement whatever it takes to make it possible to use IPSec on the box to make the boxes road warriors, starting with IKEv1 PSK setups as used by the Fritz!Box.
4. ...
simple-rsa is currently written as a Bash script. It focusses on creating keys/certs and configs in one way that suits most users. Those who believe or truely can do better configs will most likely not use it anyways.
The idea behind simple-rsa is not to make admins unemployed but to give Joe Average the chance to set up a secure and good working VPN.
SpaceRat 15 Jan 2017
-= Simple RSA =- OPENVPN MENU 1) Generate DH params (Only needed once) 2) Setup a server on THIS machine 3) - 4) - 5) Return to main menu #? 2 Enter a port for the OpenVPN server to listen on. Hint for DS-lite/CGN users: If you are going to use a port proxy like feste-ip.net or myonlineportal.net, you should create the port proxy FIRST, trying to get a 1:1 mapping and use the resulting port here! OpenVPN server port: 443 OpenVPN server port is 443 Is this correct? [Y/n] Use of routed networking (tun) or bridged networking (tap). If unsure choose TUN 1) tun 2) tap #? 1 Networking will use tun Is this correct? [Y/n] Network protocol to use for OpenVPN. Hint for DS-lite/CGN users: If you are going to use a port proxy like feste-ip.net or myonlineportal.net, you MUST use TCP, as UDP can not be proxied! If unsure choose TCP 1) tcp 2) udp #? 1 Network protocol will be tcp6 Is this correct? [Y/n]
Pippin 15 Jan 2017
Must have for OpenVPN 2.3.x:
--tls-auth (ta.key 0 server side and ta.key 1 on client side (can also be inline)
--cipher AES-128-CBC as a minimum, as it is now it`s vulnerable to SWEET32 attack
Suggestions:
1. remove --ns-cert-type server, instead use 3.
2. add --remote-cert-tls server for server side and --remote-cert-tls client for client side.
3. remove --tls-server since the directive --server already includes it.
4. add --topology subnet server side (pushed to clients automatically)
Good practice: Do not generate certificates on the box or any embedded system for that matter.
*****
Update OpenVPN to current version 2.4 so we can use tls-crypt and NCP and AES-GCM which will reduce overhead on crypto.
Someone made a start here: