[plug] clients "phone home" to server. VPN maybe?

[Daniel Pittman]

Tim <weirdit at gmail.com> writes:

> I'm starting to play with OpenVPN now. I'm wondering about the keys
> for the client machines. If I was to generate a "client" key and all
> clients connected with it, would that cause problems?

Yes.  Not on day one, but eventually, it will.  Use the supplied CA
stuff, or one of the nice GUI CA services that are packaged in modern
distributions and generate a unique client key, if you can.

You shuold have gnomint, newpki-client and -server, and possibly some
other options in at least some recent version of Ubuntu.

> The basic reason for asking is I produce an install CD, that installs
> the base system, and then (via secured SVN) gets some more software
> (custom interface's and stuff), as well as a setup script that pulls
> down patchs for all the config files and installs other specific files
> for the system.

The approach that I would take is to update this script to generate a
private machine key and a CSR, then email (or whatever) that CSR back to
you.

You can then sign that and return the certificate to the machine in some
fashion; it could be entirely automated, since you already have some
sort of security in place, if you were happy trusting that.

Altenately I would just poll every half hour to a central server, with
something like the secured SVN authentication details, until an
appropriate certificate was available.

That exposes you to some risk of a client stealing another clients key,
but not much of one — and, presumably, they already had access to the
VPN system with their own certificate. :)

> Now the simplest thing I can think of, is include a default
> certificate/key for the client machines on there, and once they are
> connected and identified to the VPN, then ssh them a client specific
> certificate/key.

That, also, would work.  A "bootstrap" VPN connection would be fine,
provided you didn't keep using it.

I would probably deploy it as a separate "shared key" OpenVPN service
with much, much tighter security wrapped around it, however.


> Also, TCP .vs. UDP. I've read much on it so far. Basically, the link
> on my side is stable, static ip, decent connection. The link on the
> other side can be anything (and knowing South Africa, it can be very
> flaky). UDP seems to be the safer option, due to packet loss and TCP
> over TCP causing issues.

*nod*  TCP-over-TCP is unreliable on good links, such as entirely within
the same ISP infrastructure in the same state in Australia.  Not /very/
unreliable, but still...

To South Africa, based on my experiece, you can expect the worst of
everything at all times.  Boy, working on servers over there was not
much fun. :)

> The majority of what needs to go over the VPN is ssh traffic and web
> traffic (to administer and monitor), both of which are TCP. But from
> what I've also read, a UDP connection may be harder to establish.

Not substantially: as long as you don't have multiple machines behind
the same crappy NAT firewall everything should be good.  OpenVPN is very
simple and, so, very robust when it comes to dealing with the network.

It is worth noting that most of the other VPN protocols over UDP have
various NAT related issues that, for OpenVPN, simply don't exist,
thankfully.

I am yet to run into a firewall, even among the junk that passes for
ADSL modems, that doesn't correctly pass OpenVPN UDP traffic.[1]

> So, do I attempt UDP with TCP fallback? Or just use TCP?

The first, if you want to be robust for an unattended remote system.


> I'm not really sure with this one what the best option is. Is there a
> way to make TCP over TCP work nicely?

No, there isn't.  It simply isn't possible.  Your only option is to use
an unreliable transport for the VPN.

Regards,
        Daniel

Footnotes: 
[1]  I have run into a situation where a firewall will get in the way,
     but never one that wouldn't also have broken TCP-based VPN services.