Yes with flexibility comes some complexity. A traditional VPN is usually an all or nothing operation, and that is simpler at a higher cost, if that's all you want to do. Until your VP or CEO tells you he wants to print at home or access his home server while he's connected remotely (happens every time I've seen a VPN implemented)...

You know your environment, and you know what the requirements are. You need to use the tool that does the job at the price point and management overhead point that you need to reach.

If you have a skill diverse population of 50,000 users, VPNs and SecureID cards may be the way to go. If you have 5 intelligent users, you can teach them ssh and you are done. Odds are it's somewhere in between, and that becomes a judgment call on your part.

Yes, I agree. Sometimes, it is some high position manager who makes decision based on whatever consideration

One last question, I am thinking about the internal server to be tunneled. It is behind some "gateway" that provides the tunnel. Since the internal server name appears as argument in "ssh -L.." command, I guess it is this "gateway" machine to resolve the internal server name. As a result, we can access internal servers with private IP addresses from remotely, even though these servers would otherwise be invisible to the Internet. Is this correct?

Thanks!

1. With the proper configuration they can access the lans resources as if connected to the lan.

2. You can do it via vpn. But if they don't start the vpn-client they connect in the common way to the
lan. The vpn-client just simulates connecting the laptop to the local lan.

3. The way a user connects to the internet doesn't matter. The client connects via the default-gateway to your vpn-server, encrypting the communication with the server.


4. Config follows (Was my first try)

Server:


# Which TCP/UDP port should OpenVPN listen on?
port 1149

# TCP or UDP server?
;proto tcp
proto udp

# "dev tun" will create a routed IP tunnel,
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).

# Ed by karpi:
# these are the servers keys/certificates.
# Howto generate them is very well documented
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
crl-verify /etc/openvpn/keys/crl.pem

# 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 /etc/openvpn/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.

# Ed by Karpi
# this is the network for the vpn.
# you have to update the routing tables of all servers, to which the users can connect.
server 10.12.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.X.Y 255.255.255.0"



# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
push "dhcp-option DNS 192.168.X.Y"
push "dhcp-option WINS 192.168.X.Y"


# 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 30 120

# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
#cipher BF-CBC # Blowfish (default)
#cipher AES-128-CBC # AES
cipher DES-EDE3-CBC # Triple-DES

# 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 10

# 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 nobody

# 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 /var/log/openvpn-status.log

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
log /var/log/openvpn.log
#log-append /var/log/openvpn.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 2

# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
mute 20


Client:
# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# 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

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
dev-node vpn

# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote vpn.mydomain.de 1194



# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun


# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description. It's best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
ca c:\\programme\\openvpn\\keys\\ca.crt
cert c:\\programme\\openvpn\\keys\\client.crt
key c:\\programme\\openvpn\\keys\\client.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server". The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
tls-auth c:\\programme\\openvpn\\keys\\ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20


This was my first working openvpn-setup.
I have 10 users working with this setup.
For security reasons this I have setup a dedicated vpn-server
(Pentium II 350,512MB RAM, 4 GB HDD)
Line is a 1MBit/1Mbit synchronus DSL
This Line is fast enough, since the users mostly connect via GPRS-Modems

The users access their mails, use the CRM, their Windows shares, the fax-server
and other internet-related services.
You _can_ push a new default-gateway to the clients, so they connect to the internet via
your proxy, firewall and other security related services.

If the users connect to the lan while at their workplace, they simply don't start the vpn-client.
There is no difference between working via vpn or directly connected to the lan.
They can print on the printers while at their workplace or to a printer connected to the laptop.

HTH

Yes, the -L parameter is resolved after the connection, and only has to be reachable by the login userid and host.

The client system's IP address is irrelevant, even if they have a public/static IP from their ISP. The VPN server will provide them with an internal IP address when connecting so that it appears as if they are part of the LAN to all resources on that LAN. The incoming connection request is coming from (as far as the VPN server can tell) the WAN connection that it has been configured with, not from a LAN or private IP address. Because resources on the LAN are generally unavailable to the internet (WAN), the VPN client is given a temporary local IP address by the VPN server.

In the case of Windoze clients (all my users use either WXP SP2 or W2k Pro on their home systems), the VPN client software is built in for PPTP connections. That was the main reason why I went with PoPToP. There is also a PPTP client for Linux clients. The configuration in Windoze is very straight-forward. Try this walkthrough for screenshots and details.

Thanks a lot for a detailed configuration. Though it will take me a while to digest

Now, it seems to me that SSH tunneling is enough for road warriors to access some internal services behind a gateway on their office LAN. But definitely OpenVPN is a solution for site-to-site VPN configuration, for example, connection branch offices. I visited openvpn.org but I didn't find any technical documentation explaining how OpenVPN works, how a routed or a bridged tunnel works, what happens when a openvpn client initiates a vpn connection with openvpn server and how a LAN computer behind a openvpn client accesses computers on private LAN behind openvpn server. Do you know such tutorials?

In addition, I have a specific configuration case that I need help, which is in another thread. If you have interests, please see that post here.

Thanks!

There are a good set of tutorials on OpenVPN in the Gentoo Wiki.

I tried to get better understanding on openvpn. However, it seems that openvpn can only be started as "root". If I log on as a normal user and run "openvpn client_config_file", openvpn fails to start and it gives the following error message:


If this is the case, then for roaming users, they have OpenVPN running when they are at local LAN and when they are on road. In case there is only one office and the OpenVPN server is the gateway between LAN and Internet, there is a problem: when a user is in his office, private IP address of the server will be used in the conf file on his laptop; when he is in an internet cafe, he needs public IP address of the server to have the VPN. Or he always uses public IP for the server?

Any thoughts? Thanks!