logo

 

This site is now 100% read-only, and retired.

Connecting to office network using OpenVPN tunnel

Posted by bigmyx on Fri 19 Jan 2007 at 10:47

Tags: ,

I wrote this article because I think that it will be useful for the people that are using Debian GNU/Linux as their home desktop and want to connect to the corporate LAN protected by CheckPoint VNP-1/NG VPN server.

I got SSH access to one of the Linux servers on DMZ used SSH port forwarding to forward SMTP and some other traffic via SSH. That was perfect until I was required to access more machines inside our corporate LAN and continue to use this solution become painful for me.

With OpenVPN I got all this working without any troubles and now I have access to all machines inside my office.

You will need a Linux machine inside your corporate LAN that that will act as a client and will initiate the VPN connection to your home Linux machine that will act as a server. The connection will be passed through UDP 2746 port that is used by CheckPoint and usually opened for outbound connections from your corporate LAN.

As for this article, there is official How-To that I used while creating it, but finally I wanted to create something that is proven by personal experience and kept as simple as it is possible.

Requirements:

  • Basic Linux knowledge
  • Two Linux machines with tun/tap device support in their Kernels one is the server and another is the client.
  • Dedicated internet IP address of your home internet connection (you probably will not have one) or DynDNS.org (or any other dynamic DNS) account.

Setting up the server:

First install the packages:

apt-get install openvpn ipcheck

NOTE - I used ipcheck for dynamic DNS update, I will not cover usage of that here since it is not related to the VPN procedure and it is pretty easy to use.

Create configuration file for the server in /etc/openvpn/server.conf:

port 2746
proto udp
dev tap
;dev-node tap0
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
dh dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0" # home subnet
;duplicate-cn
keepalive 10 120
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
comp-lzo
user nobody
group nobody
persist-key
persist-tun
;status openvpn-status.log
;log-append  openvpn.log
verb 10
mute 20
client-to-client
client-config-dir ccd "route 134.33.0.0 255.255.0.0"

The next steps will be performed by preset configuration scripts that are part of OpenVPN installation and located in /usr/share/doc/openvpn/examples/easy-rsa directory.

Generate the CA:

cd  /usr/share/doc/openvpn/examples/easy-rsa
. ./vars
./clean-all
./build-ca

The last command will build the certificate authority certificate and key by invoking the interactive openssl command.

Generate certificates & keys for server:

./build-key server

Generate certificates & keys for client:

./build-key client1

Make sure to type the appropriate Common Name when prompted, i.e. "client1"

Generate Diffie Hellman parameters

./build-dh

Place the following files in the /etc/openvpn directory on the server :

ca.crt
server.crt
dh1024.pem
server.key   - Note: This file should be kept secret!!

Create client IP addresses list file ipp.txt:

client,10.10.10.2
Setting up the client:

Install the package:

apt-get install openvpn

Create the configuration file for the client /etc/openvpn/client.conf.

remote your.ddns.host 2746
client
dev tap
proto udp
resolv-retry infinite # this is necessary for DynDNS
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 4
mute 20

Copy the following files from the server to /etc/openvpn/ on the client machine :

ca.crt
client1.crt
client1.key
Starting the server and client

It's best to initially start the OpenVPN server from the command line, rather than start it as a daemon or service for the first time :

openvpn /etc/openvpn/server.conf

Use the same command to start the client. As the normal output you should see something like that:

 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb  5 2005
 Diffie-Hellman initialized with 1024 bit key
 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
 2005 TUN/TAP device tun1 opened
 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
 UDPv4 link local (bound): [undef]:1194
 UDPv4 link remote: [undef]
 MULTI: multi_init called, r=256 v=256
 IFCONFIG POOL: base=10.8.0.4 size=62
 IFCONFIG POOL LIST
 2005 Initialization Sequence Completed

After ensuring that all the parts are working and you able to initiate the connection you may safely use the init script that comes with the OpenVPN package installation, the init script will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.

NOTE - The cute part is that you can setup VPN dedicated server at your corporate LAN that will initiate connections to multiple servers!

Post configuration actions:

After installing server and client I found my self only able to connect to the corporate LAN machine it self and not able to PING any host inside the network. Two commands (one for server and one for client) resolved the issue:

Server (home):

route add -net 134.33.0.0 netmask 255.255.0.0 gw 10.10.10.2

(10.10.10.2 is the IP address of tap0 on the remote end.)

Client (office):

iptables -t nat -A POSTROUTING  -s 10.10.10.1 -d 134.33.0.0/16 -j SNAT --to 134.33.11.110
echo "net.ipv4.conf.default.forwarding=1" >> /etc/sysctl.conf
sysctl -p

134.33.11.110 is the IP address of eth0 on the local machine.

10.10.10.1 is the IP address of tap0 on the remote (home) machine.

References:

 

 

 

#
Re: Connecting to office network using OpenVPN tunnel
Posted by Anonymous (213.134.xx.xx) on Fri 19 Jan 2007 at 11:04
Please remember that VPN is NOT a secure tunnel. The optional MPPE encryption is very weak. A Better alternative is IPsec, the IETF standard for tunnels. IPSec clients are available for almost every OS.

[ Parent ]

#
Not secure?
Posted by agi (80.25.xx.xx) on Fri 19 Jan 2007 at 11:59
Hi, I don't know what you mean by 'VPN'. Probable Microsoft's one, because you mention MPPE. But OpenVPN, and that's what the article is about, IS secure. There's more secure options than IPsec.

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by Anonymous (62.29.xx.xx) on Fri 19 Jan 2007 at 13:13
OpenVPN does not use MPPE, which indeed is very weak. OpenVPN is based on SSL, and defaults to using Blowfish and SHA1. It is very secure.

[ Parent ]

#
SHA1 is broken
Posted by amosshapira (203.10.xx.xx) on Thu 25 Jan 2007 at 03:55
Actually, SHA-1 was broken almost two years ago:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by hagakure (195.112.xx.xx) on Sat 20 Jan 2007 at 14:03
As has already been said, OpenVPN is a secure VPN.

There is official information on OpenVPN security at:

http://openvpn.net/security.html

An informative news artical at:

http://software.newsforge.com/software/05/09/22/164231.shtml?tid= 152&tid=78

A simple explanation of how OpenVPN security works at:

http://vpn.cafenetworks.co.uk/how-does-a-vpn-work.php

I hope the links are of use.

Rgds,

Hagakure

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by uroboros (86.49.xx.xx) on Tue 23 Jan 2007 at 23:32
[ View Weblogs ]
OMG WTF?

--
If you're smart enough to ask this question, you're smart enough to RTFM and find out yourself.

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by Anonymous (194.42.xx.xx) on Wed 7 Feb 2007 at 15:39
You really have no clue what you're talking about, do you!

OpenVPN does not use MPPE encryption. It can use any cipher that OpenSSL supports, which when you're talking 256-bit AES, it is really the de-facto standard for pretty well any high-encryption application right now.

IPSec is NOT a VPN tunnel, it is a host of different protocols for securing internet protocol data with encryption and authentication. One of its uses is to secure the data flowing between two endpoints, but often another protocol is used for this such as L2TP.

I reckon you should get your facts straight before posting things like this because it does really make you look like an ignorant fool ;)

leeph

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by wuzzeb (64.5.xx.xx) on Fri 19 Jan 2007 at 17:54
From the sample openvpn server config, you can add the following lines to server.conf. This will tell the server about the network behind the client.

# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
client-config-dir ccd
route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2


Also, why don't you have the office computer be the openvpn server, and your home machine the client? This is (to me) the more natural config because the office computer is on 24/7, while your home machine might not always be on. When you turn on your home machine, the openvpn init.d script will set up the connection automatically.

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by wuzzeb (64.5.xx.xx) on Fri 19 Jan 2007 at 18:06
For reference, here is my openvpn server config file. I run the client on my computer, the server on the computer in the office.

I have a network 172.16.29.0/24 behind the client (my private network here in my home, where I run openvpn in client mode on the gateway machine here in my house), and I have a 192.168.0.1/24 network behind the server in the office. I use a routed network, and the openvpn network uses 172.17.0.0/24.

This way, any computer in my home can reach any computer in the office.

# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
;proto tcp
proto udp

# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap" if you are ethernet bridging.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key).  Each client
# and the server must have their own cert and
# key file.  The server and all clients will
# use the same ca file.
#
# See the "easy-rsa" directory for a series
# of scripts for generating RSA certificates
# and private keys.  Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
#   openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys. 
dh dh1024.pem

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 172.17.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file.  If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"

# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).

# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
client-config-dir ccd
;route 192.168.40.128 255.255.255.248
route 172.16.29.0 255.255.255.0
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
route 172.17.0.0 255.255.255.0
# Then add this line to ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 27 200

# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo

# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100

# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
user nobody
group nogroup

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# Set the appropriate level of log
# file 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


Then in the ccd directory, I have a file with
iroute 172.16.29.0 255.255.255.0
ifconfig-push 172.17.0.2 172.17.0.3

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by bigmyx (89.0.xx.xx) on Fri 19 Jan 2007 at 23:00
Thanks for the examples, they were clear and useful!

My only problem that I have no administrative access in my corporate LAN.

Or corporate policy is to have CheckPoint firewall/VPN solution only...

I have no doubt that to have OpenVPN server at the office and OpenVPN client at home is ideal solution.

As I mentioned in the pre-phrase section, my article is a king of workaround for the people that have similar scenario in their offices.

The solution works fine because I don't need to "dial" manually from the client machine - it will try every 10 sec. all the time till will got actually connected to the server.

It also would be great if CheckPoint will develop diver for recent kernels. but unfortunately they don't ... from my experience their FW/VPN solutions are the best, but this is another story ;-)

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by hagakure (195.112.xx.xx) on Sat 20 Jan 2007 at 13:53
You can have a CheckPoint firewall or any other type of firewall running and still use OpenVPN.

Place the OpenVPN server inside your LAN.

On the existing firewall, port forward the traffic to the OpenVPN server. (If you are following the OpenVPN howto (http://openvpn.net/howto) this is udp traffic on port 1194

Depending on the settings of the connecting networks and your specific set-up; add a route to set the gateway for the connecting and VPN network to the existing firewall.

For example:

VPN Network 10.0.0.2
Office Network: 192.168.0.0
IP of OpenVPN server in Office Network: 192.168.0.100
Connecting Network: 172.50.0.0

On existing firewall, add the two routes (VPN Network and Connecting Network):

In Debian, this would be done with the commands:

route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.0.100
route add -net 172.50.0.0 netmask 255.255.255.0 gw 192.168.0.100

On other firewalls, please check your documentation for how to do this.

I do understand that as bigmyx has no administrative rights on his corporate LAN, and the above comments won't help, but they might help others with similar problems.

HTH

Hagakure

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by riteshsarraf (122.167.xx.xx) on Tue 30 Aug 2011 at 20:07
Thank you for this article. It is really good.

[ Parent ]

#
Re: Connecting to office network using OpenVPN tunnel
Posted by cheese528 (118.100.xx.xx) on Wed 2 Nov 2011 at 09:50
I was just reading over this, and wondering how this is different from using a tun device instead of a tap device (which is normally bridged). It appears that both networks are on different subnets anyway, so wouldn't tun (routed mode) be more suitable?

[ Parent ]