Difference between revisions of "OpenVPN"

From SlackWiki
Jump to: navigation, search
m (ADDED: Install from Slackbuilds.org)
(Moved old instructions to their own page. Made this page a menu for the instructions)
Line 6: Line 6:
 
OpenVPN is not compatible with IPSec, IKE, PPTP, or L2TP.
 
OpenVPN is not compatible with IPSec, IKE, PPTP, or L2TP.
  
'''[[OpenVPN(ID)|OpenVPN Instructions - Bahasa Indonesia]]'''
 
  
 +
[[openvpn_smcr_2012|OpenVPN server setup on Slackware 13.37]] - Multi-client with routing (not bridged). (2012)
  
__TOC__
+
[[openvpn_pre-2009|OpenVPN server/client instructions]] (Pre-2009)
== Installation ==
 
  
'''EASY WAY:'''
 
Download and install from Slackbuilds.org or sbopkg.
 
  
or
 
  
'''HARD WAY:'''
 
Install from source.
 
  
Download source from [http://openvpn.net openvpn.net]
+
[[OpenVPN(ID)|OpenVPN Instructions - Bahasa Indonesia]] (Pre-2009)
 
 
Download verison 2.0
 
 
 
install Lzo
 
<pre>
 
tar zxvf lzo-1.08.tar.gz
 
cd lzo-1-08.tar.gz
 
./configure --prefix=/usr
 
make ; make install-strip
 
</pre>
 
install OpenVPN
 
<pre>
 
tar zxvf openvpn-2.0.tar.gz
 
cd openvpn-2.0
 
./configure --prefix=/usr \
 
--sysconfdir=/etc/openvpn \
 
--enable-pthread \
 
--enable-iproute2 \
 
--with-ssl \
 
--with-lzo-header=/usr/include \
 
--with-lzo-lib=/usr/lib \
 
--with-ifconfig \
 
--with-route \
 
--with-mem-check=dmalloc
 
make ; make install-strip
 
</pre>
 
 
 
 
 
==Creating The Certificates==
 
 
 
Save all certificates in '''''/etc/openvpn/certs'''''
 
<pre>
 
This is a small RSA key management package,
 
based on the openssl command line tool, that
 
can be found in the easy-rsa subdirectory
 
of the OpenVPN distribution.
 
 
 
These are reference notes.  For step
 
by step instructions, see the HOWTO:
 
 
 
http://openvpn.net/howto.html
 
 
 
INSTALL
 
 
 
1. Edit vars.
 
2. Set KEY_CONFIG to point to the openssl.cnf file
 
  included in this distribution.
 
3. Set KEY_DIR to point to a directory which will
 
  contain all keys, certificates, etc.  This
 
  directory need not exist, and if it does,
 
  it will be deleted with rm -rf, so BE
 
  CAREFUL how you set KEY_DIR.
 
4. (Optional) Edit other fields in vars
 
  per your site data.  You may want to
 
  increase KEY_SIZE to 2048 if you are
 
  paranoid and don't mind slower key
 
  processing, but certainly 1024 is
 
  fine for testing purposes.  KEY_SIZE
 
  must be compatible across both peers
 
  participating in a secure SSL/TLS
 
  connection.
 
5  . vars
 
6. ./clean-all
 
7. As you create certificates, keys, and
 
  certificate signing requests, understand that
 
  only .key files should be kept confidential.
 
  .crt and .csr files can be sent over insecure
 
  channels such as plaintext email.
 
8. You should never need to copy a .key file
 
  between computers.  Normally each computer
 
  will have its own certificate/key pair.
 
 
 
BUILD YOUR OWN ROOT CERTIFICATE AUTHORITY (CA) CERTIFICATE/KEY
 
 
 
1. ./build-ca
 
2. ca.crt and ca.key will be built in your KEY_DIR
 
  directory
 
 
 
BUILD AN INTERMEDIATE CERTIFICATE AUTHORITY CERTIFICATE/KEY (optional)
 
 
 
1. ./build-inter inter
 
2. inter.crt and inter.key will be built in your KEY_DIR
 
  directory and signed with your root certificate.
 
 
 
BUILD DIFFIE-HELLMAN PARAMETERS (necessary for
 
the server end of a SSL/TLS connection).
 
 
 
1. ./build-dh
 
 
 
BUILD A CERTIFICATE SIGNING REQUEST (If
 
you want to sign your certificate with a root
 
certificate controlled by another individual
 
or organization, or residing on a different machine).
 
 
 
1. Get ca.crt (the root certificate) from your
 
  certificate authority.  Though this
 
  transfer can be over an insecure channel, to prevent
 
  man-in-the-middle attacks you must confirm that
 
  ca.crt was not tampered with.  Large CAs solve this
 
  problem by hardwiring their root certificates into
 
  popular web browsers.  A simple way to verify a root
 
  CA is to call the issuer on the telephone and confirm
 
  that the md5sum or sha1sum signatures on the ca.crt
 
  files match (such as with the command: "md5sum ca.crt").
 
2. Choose a name for your certificate such as your computer
 
  name.  In our example we will use "mycert".
 
3. ./build-req mycert
 
4. You can ignore most of the fields, but set
 
  "Common Name" to something unique such as your
 
  computer's host name.  Leave all password
 
  fields blank, unless you want your private key
 
  to be protected by password.  Using a password
 
  is not required -- it will make your key more secure
 
  but also more inconvenient to use, because you will
 
  need to supply your password anytime the key is used.
 
  NOTE: if you are using a password, use ./build-req-pass
 
  instead of ./build-req
 
5. Your key will be written to $KEY_DIR/mycert.key
 
6. Your certificate signing request will be written to
 
  to $KEY_DIR/mycert.csr
 
7. Email mycert.csr to the individual or organization
 
  which controls the root certificate.  This can be
 
  done over an insecure channel.
 
8. After the .csr file is signed by the root certificate
 
  authority, you will receive a file mycert.crt
 
  (your certificate).  Place mycert.crt in your
 
  KEY_DIR directory.
 
9. The combined files of mycert.crt, mycert.key,
 
  and ca.crt can now be used to secure one end of
 
  an SSL/TLS connection.
 
 
 
SIGN A CERTIFICATE SIGNING REQUEST
 
 
 
1. ./sign-req mycert
 
2. mycert.crt will be built in your KEY_DIR
 
  directory using mycert.csr and your root CA
 
  file as input.
 
 
 
BUILD AND SIGN A CERTIFICATE SIGNING REQUEST
 
USING A LOCALLY INSTALLED ROOT CERTIFICATE/KEY -- this
 
script generates and signs a certificate in one step,
 
but it requires that the generated certificate and private
 
key files be copied to the destination host over a
 
secure channel.
 
 
 
1. ./build-key mycert (no password protection)
 
2. OR ./build-key-pass mycert (with password protection)
 
3. OR ./build-key-pkcs12 mycert (PKCS #12 format)
 
4. OR ./build-key-server mycert (with nsCertType=server)
 
5. mycert.crt and mycert.key will be built in your
 
  KEY_DIR directory, and mycert.crt will be signed
 
  by your root CA. If ./build-key-pkcs12 was used a
 
  mycert.p12 file will also be created including the
 
  private key, certificate and the ca certificate.
 
 
 
IMPORTANT
 
 
 
To avoid a possible Man-in-the-Middle attack where an authorized
 
client tries to connect to another client by impersonating the
 
server, make sure to enforce some kind of server certificate
 
verification by clients.  There are currently four different ways
 
of accomplishing this, listed in the order of preference:
 
 
 
(1) Build your server certificates with the build-key-server
 
    script.  This will designate the certificate as a
 
    server-only certificate by setting nsCertType=server.
 
    Now add the following line to your client configuration:
 
 
 
    ns-cert-type server
 
 
 
    This will block clients from connecting to any
 
    server which lacks the nsCertType=server designation
 
    in its certificate, even if the certificate has been
 
    signed by the CA which is cited in the OpenVPN configuration
 
    file (--ca directive).
 
 
 
(2) Use the --tls-remote directive on the client to
 
    accept/reject the server connection based on the common
 
    name of the server certificate.
 
 
 
(3) Use a --tls-verify script or plugin to accept/reject the
 
    server connection based on a custom test of the server
 
    certificate's embedded X509 subject details.
 
IMPORTANT
 
 
 
To avoid a possible Man-in-the-Middle attack where an authorized
 
client tries to connect to another client by impersonating the
 
server, make sure to enforce some kind of server certificate
 
verification by clients.  There are currently four different ways
 
of accomplishing this, listed in the order of preference:
 
 
 
(1) Build your server certificates with the build-key-server
 
    script.  This will designate the certificate as a
 
    server-only certificate by setting nsCertType=server.
 
    Now add the following line to your client configuration:
 
 
 
    ns-cert-type server
 
 
 
    This will block clients from connecting to any
 
    server which lacks the nsCertType=server designation
 
    in its certificate, even if the certificate has been
 
    signed by the CA which is cited in the OpenVPN configuration
 
    file (--ca directive).
 
 
 
(2) Use the --tls-remote directive on the client to
 
    accept/reject the server connection based on the common
 
    name of the server certificate.
 
 
 
(3) Use a --tls-verify script or plugin to accept/reject the
 
    server connection based on a custom test of the server
 
    certificate's embedded X509 subject details.
 
 
 
(4) Sign server certificates with one CA and client certificates
 
    with a different CA.  The client config "ca" directive should
 
    reference the server-signing CA while the server config "ca"
 
    directive should reference the client-signing CA.
 
 
 
NOTES
 
 
 
Show certificate fields:
 
  openssl x509 -in cert.crt -text
 
</pre>
 
<pre>
 
# cd easy-rsa
 
# vi vars
 
. vars
 
./clean-all
 
 
 
## BUILD YOUR OWN ROOT CERTIFICATE AUTHORITY (CA) CERTIFICATE/KEY
 
./build.ca
 
 
 
## BUILD AN INTERMEDIATE CERTIFICATE AUTHORITY CERTIFICATE/KEY (optional)
 
./build-inter inter
 
 
 
## BUILD DIFFIE-HELLMAN PARAMETERS (necessary for the server end of a SSL/TLS connection).
 
./build.dh
 
 
 
## BUILD A CERTIFICATE SIGNING REQUEST
 
## (If you want to sign your certificate with a root certificate controlled by another individual
 
## or organization, or residing on a different machine)
 
 
 
./build-req mycert
 
## SIGN A CERTIFICATE SIGNING REQUEST
 
./sign-req mycert
 
 
 
## BUILD AND SIGN A CERTIFICATE SIGNING REQUEST USING A LOCALLY INSTALLED ROOT CERTIFICATE/KEY
 
./build-key mycert (no password protection)
 
OR
 
./build-key-pass mycert (with password protection)
 
OR
 
./build-key-pkcs12 mycert (PKCS #12 format)
 
OR
 
./build-key-server mycert (with nsCertType=server)
 
</pre>
 
 
 
==Configuring the Server==
 
 
 
Edit the server.conf file: '''''vi /etc/openvpn/server.conf'''''
 
<pre>
 
## Mode Server
 
mode server
 
 
 
## Local Host Name/IP Server
 
;local 127.0.0.1
 
 
 
## Protocol
 
;proto tcp
 
proto udp
 
 
 
## Port
 
; port 1194
 
 
 
## Device Interface
 
;dev tap
 
dev tun
 
 
 
## TAP-Win32 adapter name
 
;dev-node MyTap
 
 
 
## SSL/TLS
 
## root certificate (ca)
 
## certificate (cert)
 
## private key (key)
 
ca /etc/openvpn/certs/ca.crt
 
cert /etc/openvpn/certs/server.crt
 
key /etc/openvpn/certs/server.key
 
 
 
## Diffie hellman parameters
 
dh dh1024.pem
 
 
 
## VPN subnet
 
server 10.8.0.0 255.255.255.0
 
 
 
ifconfig-pool-persist ipp.txt
 
 
 
##ethernet bridging
 
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
 
 
 
## dhcpcaveats
 
;push "route 192.168.10.0 255.255.255.0"
 
;push "route 192.168.20.0 255.255.255.0"
 
 
 
;client-config-dir ccd
 
 
 
;route 192.168.40.128 255.255.255.248
 
 
 
;client-config-dir ccd
 
 
 
;route 10.9.0.0 255.255.255.252
 
 
 
;learn-address ./script
 
 
 
## dhcpcaveats
 
;push "redirect-gateway"
 
;push "dhcp-option DNS 10.8.0.1"
 
;push "dhcp-option WINS 10.8.0.1"
 
 
 
##
 
;client-to-client
 
 
 
## same "COMMON NAME" certificate/key
 
;duplicate-cn
 
 
 
## Status Connection
 
keepalive 10 120
 
 
 
## tls-auth key
 
;tls-auth ta.key 0
 
 
 
## Cryptographic cipher
 
;cipher BF-CBC        # Blowfish (default)
 
;cipher AES-128-CBC  # AES
 
;cipher DES-EDE3-CBC  # Triple-DES
 
 
 
## Link Compresion
 
comp-lzo
 
 
 
## Max Client Connections
 
;max-clients 100
 
 
 
## daemon privileges (non windows saja)
 
user nobody
 
group nobody
 
 
 
persist-key
 
persist-tun
 
 
 
## Openvpn Log
 
;log        /var/log/openvpn/openvpn.log
 
;log-append  /var/log/openvpn/openvpn.log
 
 
 
## Output Log
 
status /var/log/openvpn/openvpn-status.log
 
 
 
## Log Verbosity
 
## 0 is silent, except for fatal errors
 
## 4 is reasonable for general usage
 
## 5 and 6 can help to debug connection problems
 
## 9 is extremely verbose
 
verb 3
 
 
 
## Repeating Messages
 
;mute 20
 
 
 
## Pid File
 
writepid /var/run/openvpn.pid
 
</pre>
 
 
 
'''Routing'''
 
 
 
<pre>
 
echo 1 > /proc/sys/net/ipv4/ip_forward
 
route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2
 
</pre>
 
 
 
'''Firewall'''
 
<pre>
 
iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
 
OR
 
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
 
 
 
## Tun Device
 
iptables -A INPUT -i tun+ -j ACCEPT
 
iptables -A FORWARD -i tun+ -j ACCEPT
 
 
 
## Tap Device
 
iptables -A INPUT -i tap+ -j ACCEPT
 
iptables -A FORWARD -i tap+ -j ACCEPT
 
</pre>
 
 
 
==Configuring the Client==
 
 
 
Edit the client.conf file: '''''vi /etc/openvpn/client.conf'''''
 
<pre>
 
## Config
 
client
 
 
 
## Device Interface
 
;dev tap
 
dev tun
 
 
 
## Tap adapter name (Win only)
 
;dev-node MyTap
 
 
 
## Conectivity
 
;proto tcp
 
proto udp
 
 
 
## Server [hostname/ip] [port]
 
remote my-server-1 1194
 
;remote my-server-2 1194
 
 
 
## load-balancing
 
;remote-random
 
 
 
## resolve host name OpenVPN server
 
resolv-retry infinite
 
 
 
# local port
 
nobind
 
 
 
## privileges (non windows saja)
 
user nobody
 
group nobody
 
 
 
## preserve
 
persist-key
 
persist-tun
 
 
 
## HTTP proxy
 
;http-proxy-retry
 
;http-proxy [proxy server] [proxy port]
 
 
 
## duplicate packet warnings
 
;mute-replay-warnings
 
 
 
## SSL/TLS parms
 
/etc/openvpn/certs/ca ca.crt
 
/etc/openvpn/certs/cert client.crt
 
/etc/openvpn/certs/key client.key
 
 
 
## nsCertType key
 
;ns-cert-type server
 
 
 
## tls-auth key
 
;tls-auth /etc/openvpn/certs/ta.key 1
 
 
 
## Cryptographic cipher
 
;cipher x
 
 
 
## Link compression
 
comp-lzo
 
 
 
## verbosity
 
## 0 is silent, except for fatal errors
 
## 4 is reasonable for general usage
 
## 5 and 6 can help to debug connection problems
 
## 9 is extremely verbose
 
verb 3
 
 
 
## repeating messages
 
;mute 20
 
</pre>
 
'''Routing'''
 
<pre>
 
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1
 
</pre>
 
 
 
==Example==
 
 
 
'''Example 1:''' A simple tunnel without security<br>
 
'''On May: Server Side'''
 
<pre>
 
openvpn --remote jun.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 9
 
</pre>
 
 
 
'''On Jun: Client Side'''
 
<pre>
 
openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --verb 9
 
</pre>
 
 
 
On May:
 
    ping 10.4.0.2
 
 
 
On Jun:
 
    ping 10.4.0.1
 
 
 
'''Example 2:''' A tunnel with static-key security (i.e. using a pre-shared secret)<br>
 
'''On May: Server Side'''
 
<pre>
 
openvpn --remote jun.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 \
 
--verb 5 --secret key
 
</pre>
 
 
 
'''On Jun: Client Side'''
 
<pre>
 
openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 \
 
--verb 5 --secret key
 
</pre>
 
 
 
On May:
 
    ping 10.4.0.2
 
 
 
On Jun:
 
    ping 10.4.0.1
 
 
 
'''Example 3:''' A tunnel with full TLS-based security <br>
 
'''On May: Server Side'''
 
<pre>
 
openvpn --remote jun.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 \
 
--tls-client --ca tmp-ca.crt --cert client.crt --key client.key \
 
--reneg-sec 60 --verb 5
 
</pre>
 
 
 
'''On Jun: Client Side'''
 
<pre>
 
openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 \
 
--tls-server --ca tmp-ca.crt --cert server.crt --key server.key \
 
--reneg-sec 60 --verb 5 --dh dh1024.pem
 
</pre>
 
 
 
On May:
 
 
 
    ping 10.4.0.2
 
 
 
On Jun:
 
 
 
    ping 10.4.0.1
 
 
 
== External Links ==
 
 
 
* http://dmalloc.com/
 
* http://valgrind.org/
 
* http://www.oberhumer.com/opensource/lzo/
 
* http://openvpn.net/
 
* http://openvpn.net/howto.html
 
* http://openvpn.net/1xhowto.html (Old-v1.06)
 
* http://openvpn.net/man.html
 

Revision as of 19:10, 9 June 2012

As a user-space VPN daemon, OpenVPN is compatible with with SSL/TLS, RSA Certificates and X509 PKI, NAT, DHCP, and TUN/TAP virtual devices.

OpenVPN is not compatible with IPSec, IKE, PPTP, or L2TP.


OpenVPN server setup on Slackware 13.37 - Multi-client with routing (not bridged). (2012)

OpenVPN server/client instructions (Pre-2009)



OpenVPN Instructions - Bahasa Indonesia (Pre-2009)