{"id":947,"date":"2019-06-05T06:39:22","date_gmt":"2019-06-05T12:39:22","guid":{"rendered":"https:\/\/wmbuck.net\/blog\/?p=947"},"modified":"2019-11-05T18:16:00","modified_gmt":"2019-11-06T01:16:00","slug":"setting-up-openvpn-server","status":"publish","type":"post","link":"https:\/\/wmbuck.net\/blog\/?p=947","title":{"rendered":"Setting Up Openvpn Server"},"content":{"rendered":"<p>The objective of this project was to install a vpn server on one of the boxes in the cloud (initially asafoetida, then moved to tarragon), in order to provide a VPN server service for a friend who was traveling. My friend uses the name Darrell for his client, so in what follows the vpn is called by this name.<\/p>\n<h5>Create a Certificate Authority<\/h5>\n<p>A lot of the instructions, even from openvpn site, say to use the \u201ceasyrsa\u201d package to generate the certificates for openvpn. This package seems to be put out by the openvpn boys, or at least with their cooperation. But I didn\u2019t do that. I created a ca with raw openssl.<\/p>\n<p><!--more--><\/p>\n<p>I built the ca on my laptop\u00a0 in \/etc\/ssl\/mycerts\/ca. The root ca is in that directory, but a subdirectory called intermediate has an intermediate ca, and that is where the actual signing is done. I probably won\u2019t leave it on the laptop. Not sure yet what I will do with the ca.<\/p>\n<h5>Generate the private keys and certificates<\/h5>\n<p>Once the ca is in place, we generate the certificates for server and client as follows:<\/p>\n<p>First I generated 2048 private keys, one for server, one for client, with:<br \/>\n<code>openssl genrsa -aes256 -out client.key 2048<\/code><br \/>\n<code>openssl genrsa -aes256 -out server.key 2048<\/code><\/p>\n<p>and generated the csr (one for each), using those keys with:<br \/>\n<code>openssl req -new -sha256 -key client.key -out client.csr<\/code><br \/>\n<code>openssl req -new -sha256 -key server.key -out server.csr<\/code><\/p>\n<p>There are directories within \/etc\/ssl\/mycerts\/ca\/intermediate, certs\/ for the certs, and csr\/ for the requests:<\/p>\n<p>Now use the csr to generate the certs (one for each):<br \/>\n<code>cd \/etc\/ssl\/mycerts\/ca\/intermediate<br \/>\nopenssl ca -config openssl.cnf -days 365 -notext -md sha256 -extensions server_cert -in csr\/server.csr -out certs\/darrell_server.cert.pem<\/code><br \/>\n<code><br \/>\nopenssl ca -config openssl.cnf -days 365 -notext -md sha256 -extensions usr_cert -in csr\/client.csr -out certs\/darrell_client.cert.pem<\/code><\/p>\n<p>I also created a diffie-hellman parameter for the link:<br \/>\n<code>openssl dhparam -out dhparams.pem 4096<\/code><\/p>\n<p>And I generated a &#8220;ta key&#8221;, which is apparently a shared key used to resist certain attacks:<br \/>\n<code>openvpn --genkey --secret \/etc\/openvpn\/ta.key<\/code><\/p>\n<p>Also on both server and client sides, I had to build the config files for openvpn. They are called, respectively, darrell.server.conf and darrell.vpn.conf. Maybe I should have called the latter darrell.client.conf. The client side is shown later on. Here is the server side configuration file:<\/p>\n<p><code><br \/>\n[root@tarragon server]# cat darrell.server.conf<br \/>\nport 1194<br \/>\nproto udp<br \/>\ndev tun<br \/>\nca \/etc\/openvpn\/server\/ca-chain.cert.pem<br \/>\ncert \/etc\/openvpn\/server\/certs\/darrell_server.cert.pem<br \/>\nkey \/etc\/openvpn\/server\/private\/server.key<br \/>\ndh \/etc\/openvpn\/server\/dhparams.pem<br \/>\ntopology subnet<br \/>\nserver 10.8.0.0 255.255.255.0<br \/>\nifconfig-pool-persist ipp.txt<br \/>\npush \"redirect-gateway def1 bypass-dhcp\"<br \/>\npush \"dhcp-option DNS 8.8.8.8\"<br \/>\npush \"dhcp-option DNS 1.1.1.1\"<br \/>\nkeepalive 10 120<br \/>\ntls-auth \/etc\/openvpn\/server\/ta.key 0<br \/>\ncipher AES-256-CBC<br \/>\ncompress lz4-v2<br \/>\npush \"compress lz4-v2\"<br \/>\nuser nobody<br \/>\ngroup nobody<br \/>\npersist-key<br \/>\npersist-tun<br \/>\nstatus \/etc\/openvpn\/server\/darrell-status.log<br \/>\nverb 3<br \/>\nexplicit-exit-notify 1<br \/>\ntls-auth ta.key 0<br \/>\nauth SHA512<br \/>\n<\/code><\/p>\n<p>Ok, so on the server (asafoetida initially, later moved to tarragon), in \/etc\/openvpn\/server, I have the following files:<br \/>\n<code>ca-chain.cert.pem<br \/>\ncerts\/darrell_server.cert.pem<br \/>\ndhparams.pem<br \/>\nprivate\/server.key<br \/>\ndarrell.server.conf<br \/>\nta.key<\/code><\/p>\n<p>The file ca-chain.cert.pem has in it both the certificate for the intermediate ca and the certificate for the root ca which signed the intermediate. Both of these are needed on the server side, for sending to the client. Later, when we build the client side, it really only needs the root ca cert.<\/p>\n<p>Initially, I started the openvpn server manually, with:<br \/>\n<code>cd \/etc\/openvpn\/server<br \/>\nopenvpn darrell.server.conf<\/code><\/p>\n<p>But see below discussion of automatic startup.<\/p>\n<h5>Client Side<\/h5>\n<p>On the client side (on lemongrass), in \/etc\/openvpn\/client, I have these files:<br \/>\n<code>client.key<br \/>\ndarrell_client.cert.pem<br \/>\ndarrell.vpn.conf<\/code><\/p>\n<p>And on lemongrass also, I (initially) started the client manually with:<br \/>\n<code>cd \/etc\/openvpn\/client<br \/>\nopenvpn darrell.vpn.conf<\/code><br \/>\nHere is the entire client config file \/etc\/openvpn\/client\/darrell.vpn.conf:<br \/>\n<code>root@lemongrass:#cd \/etc\/openvpn\/client<br \/>\nroot@lemongrass:#cat darrell.vpn.conf<br \/>\nclient<br \/>\ndev tun<br \/>\nproto udp<br \/>\nremote 54.203.69.119 1194<br \/>\nresolv-retry infinite<br \/>\nremote-random<br \/>\nnobind<br \/>\npersist-key<br \/>\npersist-tun<br \/>\nping 15<br \/>\nping-restart 0<br \/>\nping-timer-rem<br \/>\nreneg-sec 0<br \/>\nexplicit-exit-notify 3<br \/>\nverb 3<br \/>\npull<br \/>\nfast-io<br \/>\ncipher AES-256-CBC<br \/>\nauth SHA512<br \/>\ncert darrell_client.cert.pem<br \/>\nkey client.key<br \/>\nremote-cert-tls server<br \/>\n&lt;ca&gt;<br \/>\n-----BEGIN CERTIFICATE-----<br \/>\nMIIF5DCCA8ygAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwgYcxCzAJBgNVBAYTAlVT<br \/>\nMREwDwYDVQQIDAhDb2xvcmFkbzETMBEGA1UEBwwKQnJvb21maWVsZDETMBEGA1UE<br \/>\n...<\/code><\/p>\n<p>&#8212;&#8211;END CERTIFICATE&#8212;&#8211;<br \/>\n&#8212;&#8211;BEGIN CERTIFICATE&#8212;&#8211;<br \/>\nMIIF9jCCA96gAwIBAgIJAMrX0lux8xc+MA0GCSqGSIb3DQEBCwUAMIGHMQswCQYD<br \/>\nVQQGEwJVUzERMA8GA1UECAwIQ29sb3JhZG8xEzARBgNVBAcMCkJyb29tZmllbGQx<br \/>\n&#8230;<\/p>\n<p>&#8212;&#8211;END CERTIFICATE&#8212;&#8211;<br \/>\n&lt;\/ca&gt;<br \/>\nkey-direction 1<br \/>\n&lt;tls-auth&gt;<br \/>\n#<br \/>\n# 2048 bit OpenVPN static key<br \/>\n#<br \/>\n&#8212;&#8211;BEGIN OpenVPN Static key V1&#8212;&#8211;<br \/>\nfb167340f0c74c249b435dcddc75e7e7<br \/>\nadffe06ea124488cf244724749306f6f<br \/>\n&#8230;<\/p>\n<p>&#8212;&#8211;END OpenVPN Static key V1&#8212;&#8211;<br \/>\n&lt;\/tls-auth&gt;<\/p>\n<h5>Firewall adjustments<\/h5>\n<p>The server is an amazon ec2 instance, and all ec2 instances have a firewall, called a \u201csecurity group\u201d provided by amazon. I used the same \u201csecurity group\u201d rules at the amazon level for asafoetida as for tarragon (http+mail+ssh, etc), but with an additional rule to admit udp 1194.<\/p>\n<p>On asafoetida proper, there was not an additional iptables firewall \u2013 it had a default Accept-Accept-Accept filter table and no nat table. I added a couple of forward rules to filter, to accept forwarding of tun+ to eth0 and eth0 to tun+. Also I added a nat table postrouting rule to masquerade all output through eth0 to the vpn address.<\/p>\n<p>On tarragon, the default redhat firewall sends forward traffic through the input chain (?), and I only had to accept udp 1194, and accept tun+., and add the nat table postrouting, so in \/etc\/sysconfig\/iptables I added:<br \/>\n<code>-A RH-Firewall-1-INPUT -i tun+ -j ACCEPT<br \/>\n-A RH-Firewall-1-INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT<\/code><\/p>\n<p>I had not previously had a nat table in the tarragon firewall, so I had to put one in:<br \/>\n<code>*nat<br \/>\n:PREROUTING ACCEPT [4:240]<br \/>\n:INPUT ACCEPT [4:240]<br \/>\n:OUTPUT ACCEPT [2:135]<br \/>\n:POSTROUTING ACCEPT [2:135]<br \/>\n-A POSTROUTING -s 10.8.0.0\/24 -o eth0 -j MASQUERADE<\/code><\/p>\n<p>The link gets made, and the routing table on both client and server seem to be adjusted properly, but traffic doesn\u2019t flow out of the server. The problem turned out to be that I had failed to turn on ip forwarding on the box.<br \/>\n<code>echo \u201c1\u201d &gt; \/proc\/sys\/net\/ipv4\/ip_forward<\/code><\/p>\n<p>And to make that last, I put it in \/etc\/sysctl<br \/>\n<code>net.sys.ipv4.ip_forward = 1<\/code><\/p>\n<h5>Starting Automatically<\/h5>\n<p>There are systemd instance scripts for starting a client (openvpn-client@) and for starting a server (openvpn-server@). So if you put a conf file in the \/etc\/openvpn\/client directory named fred.conf, you can then do:<code><br \/>\nsystemctl enable openvpn-client@fred<\/code><\/p>\n<p>And similarly, for an openvpn server config named darrell.conf in \/etc\/openvpn\/server:<code><br \/>\nsystemctl enable openvpn-server@darrell<\/code><\/p>\n<h5>Revoking Certificates<\/h5>\n<p>This is just a parenthetical note, to record one additional bit of experience, to help me remember. I had to reissue the certs because I failed the first time to specify the \u201cextensions\u201d part. However, you cannot reissue a cert with the same common_name (i.e. you can\u2019t generate a new cert using the same csr) until you remove the old cert, which is a better practice anyway.<br \/>\n<code>openssl ca -config openssl.cnf -revoke certs\/darrell_server.cert.pem<\/code><\/p>\n<p>Then I reissued the 2 certs, with the names server2 and client2. But that isn&#8217;t relavent to these instructions, and so in the instructions above I continued to reference the certs as darrell_server.cert.pem and darrell_client.cert.pem, even though on the box the names really had the &#8220;2&#8221; appended.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The objective of this project was to install a vpn server on one of the boxes in the cloud (initially asafoetida, then moved to tarragon), in order to provide a VPN server service for a friend who was traveling. My friend uses the name Darrell for his client, so in what follows the vpn is &hellip; <a href=\"https:\/\/wmbuck.net\/blog\/?p=947\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Setting Up Openvpn Server<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,11,10,4,33,9,48],"tags":[],"class_list":["post-947","post","type-post","status-publish","format-standard","hentry","category-cloud","category-encryption","category-fedora","category-linux","category-security","category-ubuntu","category-vpn"],"_links":{"self":[{"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/947"}],"collection":[{"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=947"}],"version-history":[{"count":17,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/947\/revisions"}],"predecessor-version":[{"id":974,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/947\/revisions\/974"}],"wp:attachment":[{"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=947"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=947"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wmbuck.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=947"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}