VPN notes

From Helpful
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


VPN makes things appear as if they are on the same network, typically through an emulated network card so that it hooks into the hosts's normal networking logic.

VPN may optionally do authentication (details differ between roaming-user an site-to-site case), encryption, and compression.

VPNs are often either site-to-site connecting different networks transparently, e.g. over the internet, or remote-access, adding separate (roaming) users onto an always-on VPN network. The difference can be very subtle, but the distinction can be significant to expectations and to config details.

VPN is also sometimes used to separate parts of intranets, though virtual LANs (VLANs) are preferable where switches support them.


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Generic VPN support built into operating systems and generic client is often one of (L2TP-based) IPSec, PPTP, or SSTP

Some relevant protocols:

  • PPTP (Point-to-Point Tunneling Protocol)
    • the widest supported type, and probably the most used
    • the setup is client-server, so it is more suited to roaming-user case than to site-to-site case(verify)
    • interoperability isn't ideal; authentication and encryption are not standardized, so two PPTP-based products may be incompatible, or may only work if you disable a bunch of these features
    • somewhat flawed security in the authentication part; not the best option if you care about security
    • TCP protocol on port 1723
    • http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol
  • Tunneling via SSL / TLS connections
    • Commonly used for site-to-site(verify)), also usable for roaming-user(verify))
    • OpenVPN does this(verify)
  • Single-product-specific protocols

Product-specific notes

poptop/pptpd notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

...introduced with the example case "Don't care about the security stuff, I just want access to my home LAN":

  • I just want to get at my home shares
  • I don't want to route any other traffic through the VPN (i.e. VPN is specifically not my gateway), so no routing beyond basic subnet logic

...which, yes, can conflict if accessed from another home network which uses the 192.168/24 subnet I have at home. (which can be a reason to set your home setup to 192.168.not0or1/24 to make that a bunch less likely)

Basic configuration
is pptpd's main configuration file. You'll probably want at least:
# Load ppp and auth options from...
option /etc/ppp/options.pptpd

# log a lot of stuff until it actually works (...then comment this out)

# Log connects and disconnects to your syslog

## The following are specific to your server-end network setup.
# Our PPTP server's IP
# the IPs to give out to clients (these are exclusive with my DHCP)

# Arbitrary name (mostly internal), but note it must match the chap-secrets entry
name pptpd

# Auth/handshake
#  MSCHAP-V2 is the one that's decently secure on the network

# If you want to require encryption:   (I left this out)
# Use lock file for connection
# No compression
# No logging to terminal window
Use of CHAP means it'll look in
# client        server  secret                  IP addresses
me            pptpd   mypassword              * 
homebork      pptpd   "foo bar"     
# The second column has to match the name you set above
# passwords are in plain text

The server will also

  • need to allow IP forwarding, e.g. via sysctl but in the long term likely by editing /etc/sysctl.conf to have:
(and if you don't like reboots, reloading it via
sudo sysctl -p
  • need to have firewall rules to allow the relevant traffic, which depending on the restrictiveness of existing policies may include any of:
# Allow GRE traffic (which is IP protocol type 47)
# The relevant interface is usually the easiest thing to filter on, though it could use the IP (if static).
iptables -A INPUT -p gre -i eth0 -j ACCEPT

# allow connections to pptpd's port
iptables -A INPUT -p tcp --dport 1723 -d FIREWALL_IP -j ACCEPT

# allow forwarding traffic
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# if you want clients to talk to each other
iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables -I INPUT -s -i ppp0 -j ACCEPT
iptables --append FORWARD --in-interface eth0 -j ACCEPT

TODO: read:


This hasn't been updated for a while, so could be outdated (particularly if it's about something that evolves constantly, such as software).

Hamachi sets up a P2P-style VPN, and being a company's product is made to be easier to work with than most infrastructure tools or nerd projects.

You can set up multiple networks, for example for different circles of friends (note that the free version has a limitation on networks), which show up as basic networks in the 5.x.x.x range.

command line (*nix)

Users have their own configuration, stored in their home directories. A package manager setup probably installed a specific hamachi user to be used as the system hamachi network. If you can start a service called hamachi and you see a ham0, this is the case. It's just not being used yet; no networks joined and all.

If you give commands as root you'll add and configure a hamachi interface for root. If you want to use a single hamachi network, force the config directory to be /etc/hamachi by adding
-c /etc/hamachi/
to all commands.

You could add an alias like:

alias hamachi="hamachi -c /etc/hamachi "

This implies always using that configuration directory. (You can of course name the alias something else, like hamachiservice, to be able to both run a system and a root network)

You can often set up your computer so the service starts up and logs in at boot time, which makes it a no-brainer to use. The following is meant mostly as an option overview:

You, login, daemon:

  • hamachi
    shows status (when started)
  • hamachi start
    (also logs in)
  • hamachi stop
  • hamachi set-nick nickname
  • hamachi login
  • hamachi logout


  • hamachi list
    lists the networks you're on, and members
  • hamachi join networkname [password]
    lists the networks you're on, and members
  • hamachi go-online networkname
  • hamachi go-offline networkname
  • hamachi create networkname
    creates a network (joins it, but does not automatically go online in it)
  • hamachi delete networkname
    deletes a network you created

  • hamachi evict networkname 5.x.x.x
  • hamachi get-nicks
    lists the nicks of peers

OpenVPN notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Network-wise, OpenVPN can do a various of different things. Which also makes it flexibile enough that it makes it hard to get into from scratch.

It's available for most common platforms. OpenVPN has its own protocol, and does not interact with other types of VPN.

Commonly uses 1194/UDP for transport (optionally 1194/TCP for transport instead), and 443/TCP is also seen.

Auto-start and auto-connect

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

In windows:

Perhaps the easiest is to create a shortcut to something like:

C:\Program Files (x86)\OpenVPN\bin\openvpn-gui.exe" --connect my.ovpn

...and hook it into your startup some way (e.g. Task Scheduler)

(Note that running this more than once will just say that the OpenVPN GUI is already running. This may only matter to you if you want to connect more than one.)

The larger issue is the credentials. OpenVPN does not make it simple to store a password in a config file -- because plaintext passwords in a file is bad security.

If you don't care about that, then:

  • ensure you use OpenVPN >2.3 (verify)
  • Create a plain-text file with just username on the first line, the password on the second
  • change/add a line in your .ovpn file like:
auth-user-pass auth.txt

Semi-sorted notes

On the 'Common Name'

Common Name (CN) is the name you used when generating the certificate being authenticated with.

At login time, the CN controls some behaviour, including leases (if any).

If your server uses
, the effective CN is the username you use in authentication.

On assigning IP addresses

OpenVPN servers by default serve their own DHCP on the nets they create.

The line that tells OpenVPN what address pool to pick from is:


To make for persistent leases (reuse IPs when old lease is known), use (and read the documentation for):

ifconfig-pool-persist dir amt

This can make sense when you want IPs constant per client / user.

Servers can also assign/remember IPs (send any client config, really) for specific CNs. Note that this doesn't always let you guarantee a specific piece of hardware always gets the same IP, in that username-as-common-name and/or allowing duplicate login can mess with that.

Specify a directory with client-config-dir (probably under /etc/openvpn), and create files there with the applicable Common Name (spaces become underscores(verify)) containing any specific configuration. To force an IP:


This does not (yet?) interact cleanly with automatic assignment, so if you want to have one net contain both some fixed hosts and dynamic clients, then you probably want to decide e.g. "everything static goes under 50, and 50 and above is the dynamic pool", e.g.:

server nopool

This example is for tun-style /30 networks. In routed mode, each connection to the server is on its own little /30 network, which will be routed to each other only if you enable client-to-client in server config (The reason for /30 seems to be both compatibility with the Windows TAP driver, and to make it easier to not route clients to each other).

OpenVPN can be told either to use

proto udp 


proto tcp 

UDP is likely to perform better in many real cases.

If your firewall restricts you to TCP, use that.

If you want both, run two instances.

Static key, own PKI, or

A static key is basically a shared secret that is just a little better than a plain password. It should really only be used for point-to-point (i.e. single-client) setups.

openvpn --genkey --secret static.key

Running a simple PKI means your server is the certificate authority all other certificates relate to. This lets you can give each client their own certificate, and can revoke them, so have independent two-factor auth. (It may be easier and acceptably secure to have groups of people share certificates, or even hand out just one, in that that still rather limits the ability for online brute forcing).

The setup is a bit involved, in that there necessarily are a whole bunch of files involved. See e.g. the table on this age (search for Key files)

easy-rsa is one way to ease creating all that stuff.

Serving choices - network level

port 443
proto tcp-server
dev tun0

Tun or tap:

  • "dev tun" will create a routed IP tunnel, usually enough
  • "dev tap" will create an ethernet tunnel, sometimes more useful or necessary

Optional: port-share lets you have one port where

  • openVPN clients use it as VPN
  • other clients will get proxied to another port (when they start by not speaking openVPN)

You can e.g. effectively host both a web server and OpenVPN on port 80 and/or 433. (note that if you want to run that web server on the same host, it will have to be on a different port)

Requires proto tcp, which isn't as fast as using UDP.

If bridging, use server-bridge. Either with

OpenVPN doing DHCP-like config pushing
server-bridge gateway netmask pool-start-IP pool-end-IP
letting through the host DHCP
server-bridge [nogw]

See also [1]

If using a private network, the
directive specifies the private network to be on (has a bunch of consideration of topology and such). By default it also implies the IP pool to push to its clients.

Simple example:


If you e.g. want to reserve some IPs for static-DHCP-like behaviour:

server nopool


  • you can push route table entries to let clients reach other private networks on the server.
(Note that those will often also need route entries to know about us)

Simple home server

Some choices you need to make:

  • default route or not:
    • "I just want to get to my own home server, NAS, or such, and specifically do not want to route internet traffic through the VPN
    • "I want to surf without being snooped, whereever I am"
  • subnet routing
    • I want clients to only see the server
    • I want clients to see each other too (client-to-client, route
  • networking:
    • isolate all clients within a private net (server, dev tun)
    • bridging onto your existing LAN (server-bridge, dev tap)
  • Auth
    • certificate-supported (secure but more work up-front)
    • static pre-shared key

It is probably easiest to find an example configuration and adapt it. OpenVPN's own (/usr/share/doc/openvpn/examples/sample-config-files) may be a good start

Run as daemon (either end):

user nobody
group nobody

Setup includes:

  • making a certificate
    • making sure time is halfway right (certificate lifetime validity)

Generic tweaks



Disable Nagle


Keepalive stuff (both ends)

keepalive 10 60
# meaning ping every 10 seconds, assume dead if no pong longer than 60

Routing all traffic through the VPN

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

See http://openvpn.net/index.php/open-source/documentation/howto.html#redirect



Windows client

error 619

"A connection to the remote computer could not be established, so the port used for this connection was closed"

Seems to include any reason for the remote end to disconnect (a connection it has previously accepted), including:

  • authentication failure (verify)
  • the server-end vpn software crashing
  • firewalling of one port but not another(verify)

If you easily can, see if the server-end logs say anything interesting.

Error 868

"The remote connection was not made because the name of the remote access server did not resolve"

Name resolution problem

My mistake was adding a port in the hostname field (like vpn.example.com:234) when the relevant VPN client did not expect one there at all.

Error 800

"The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPSec negotiation might not be configured properly."


You may get a more informative error if you change type from "Automatic" to whatever you actually use.

Error 809

error 2147952461

See also