[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenVPN server mode usage?

> Recently the DDNS server hasn't been updating and I've wondered
> about other configurations.

But an openvpn configuration shouldn't be depending upon dynamic dns.
Have your dynamic IP client contact your server.  If the server is
static and known then there shouldn't be a problem if the client ip
address is dynamic and changes and isn't known.  On sites I maintain
since the IP address is static and known I use the IP address directly
so as to avoid any dependency upon dns.  (Especially if dns is using
the vpn then it would be a circular dependency to use the dns name.
In which case I must use the IP address directly and avoid the
circular dependency.  But it is static so that is okay.)

> One possibility appears to be for Dalton to run in server mode and
> for Joule to be an OpenVPN client.

That is the standard operating mode for my laptop.  It connects as a
client from wherever it happens to be in the world to my server with
the static ip address.  Then all traffic is routed over the vpn.  (And
so the Firesheep issue is not a problem for my laptop on some random
wifi network.  The issue is moved to my server network where I have
more control.  It is still a problem but just on a different but more
safe network.)

> So I'm thinking to remove option "remote joule.yi.org" 

I have never had a "remote" configuration on the server.  That is for
the client on the dynamic IP.  I think you might be able to use almost
the same configuration you currently have but just with some tweaks.

> and add "mode server" in the configuration file on Dalton.
> No such thing as "mode client".  Is a client connection 
> profile necessary on Joule when there is only one server?
> Any comments or criticisms or suggestions before I blunder 
> further?

There are two main configurations.  One is a special case shared key.
That has the advantage of being very simple to set up.


The disadvantage of the above is that it only works for two hosts.  It
doesn't scale to more.  But you might start there as a simple way to
get experience with the configuration.  It will work fine with one
server with a static IP and one client with an unknown dynamic IP.

The second main way is to set up a certificate authority and enable
multiple clients with your server.  It is more complicated but if you
are patient to work through the instructions it works quite well.


I started with the static key configuration between two hosts and
eventually migrated to the CA configuration when I wanted to add a
additional client host.  Since then I have set up a couple of more
vpns between sites and I start with the CA configuration.

OpenVPN works well.  However it isn't completely trivial to set up and
I also have needs for something simpler.  Therefore I also use autossh
in addition to openvpn.  It is a Debian package and you can install it
directly.  Autossh is quite useful.


In short I use autossh to connect a host on a dynamic IP address to a
server and to port forward connections back to the dynamic IP host.
There are a few example scripts with the package.  Unfortunately
autossh does not package with an example /etc/init.d script to have it
automatically start at boot time from the machine.  That is the way I
configure it.  I would be happy to share those files if there is

Autossh is extremely simple and very reliable.  It enables me to have
a way to always connect to the dynamic IP host without needing dynamic
dns for it.  It enables a host behind a NAT firewall (such as my
laptop connected to a private network) to be connected through a
secure encrypted vpn-like connection to a server.

My advice would be to try autossh and to port forward the ssh port to
a local port on the server.  That will give you an access path outside
of openvpn.  That way if you break your openvpn configuration during
the transition you can use the ssh port forward for access.  Then
change your openvpn configuration.  Having the two dual connection
paths will prevent a mistake on one from blocking you for access
because you can use the other path.


Attachment: signature.asc
Description: Digital signature

Reply to: