Re: [gentoo-user] Re: replacement for ftp?

[Mick]

On Sunday 14 May 2017 11:35:29 Kai Krakow wrote:
> Am Sun, 14 May 2017 09:52:41 +0100
>
> schrieb Mick <michaelkintzios@×××××.com>:
> > On Saturday 13 May 2017 23:58:17 R0b0t1 wrote:
> > > I had some problems setting up OpenVPN that were solved by using
> > > per-client public keys. That seems to be the best supported
> > > configuration (as well as the most secure). Windows-side using
> > > OpenVPN-GUI is very easy.
> > >
> > > OpenVPN tends to have poor bandwidth due to overhead, but that may
> > > be in large part due to my connection.
> >
> > OpenVPN is not the most efficient VPN implementation for connections
> > to a server because it is not multithreaded
>
> Probably true but it works well here for connections of up to 100 MBit.

It can work well for well above that throughput, but the limitation is the 
tun/tap mechanism and the CPU of the device/PC it is running on.


> > and also because unlike
> > IKE/IPSec it operates in userspace, not in kernelspace.
>
> IPsec also doesn't work without help from userspace processes.

Sure, but this is only for managing the (re)keying process, which BTW takes 
longer with IKE than with OpenVPN (we're talking about milliseconds here).  
Once the keys have been agreed and set up between peers the rest happens 
exceedingly fast in kernelspace, managed as a network layer interface (L3).  I 
recall seeing IPSec tunnels running 10 times faster than OpenVPN, being 
processed even faster than VLAN trunking, but this is very much dependent on 
the resources of the device running the tunnel.


> But I
> see what you mean: With OpenVPN, traffic bounces between kernel and
> userspace multiple times before leaving the machine. But I don't really
> see that as a problem for the scenario OpenVPN is used in: It best fits
> with dial-up connections which are really not gigabit yet. For this,
> performance overhead is almost zero.

Yes, at dial-up throughput even a smart phone has enough resources to manage 
OpenVPN without it becoming a constraint.


> IPsec can be a big pita if NAT is involved. For Windows client, L2TP
> may be a good alternative.

IKE/IPSec uses NAT-Traversal (NAT-T) by encapsulating ESP packets within UDP 
over port 4500.  This will allow clients to initiate a connection with the 
server over port 500 and then switch to 4500 as part of NAT-T detection.  
Trivia:  many routers/VPN concentrators use Vendor ID strings to determine if 
the remote peer can implement NAT-T among other attributes to shorten this 
NAT-T detection process.

Of course the server will have to be accessible over port 500 for the clients 
to be able to get to it, but this is a port forwarding/DMZ network 
configuration exercise at the server end.


> > > > The ftp server already doesn't allow unencrypted connections.
> > > >
> > > > Now try to explain to ppl for whom Filezilla is too complicated
> > > > how to set up a VPN connection and how to secure their LAN once
> > > > they create the connection (if we could ever get that to work).
> > > > I haven't been able to figure that out myself, and that is one of
> > > > the main reasons why I do not have a VPN connection but use ssh
> > > > instead.  The only disadvantage is that I can't do RDP sessions
> > > > with that ---  I probably could and just don't know how to ---
> > > > but things might be a lot easier if wireguard works.
> >
> > If the users are helpless then you may be better configuring a VPN
> > tunnel between their Internet gateway and the server, so they can
> > access the server as if it were a local share, or using the built in
> > ftp client that MSWindows comes with.  SMB will work securely in this
> > case too.
>
> This is what I would recommend, too. Put the VPN endpoints on the
> network edges and no clients needs to worry: They just use the
> connection.

If there is a large number of client PCs this is the only sane solution.


> >  [...]
> >
> > > > I'm finding it a horrible nightmare, see above.  It is the most
> > > > difficult thing you could come up with.  I haven't found any good
> > > > documentation that explains it, the different types of it, how it
> > > > works, what to use (apparently there are many different ways or
> > > > something, some of which require a static IP on both ends, and
> > > > they even give you different disadvantages in performance ...),
> > > > how to protect the participants and all the complicated stuff
> > > > involved.  So far, I've managed to stay away from it, and I
> > > > wouldn't know where to start.  Of course, there is some
> > > > documentation, but it is all confusing and no good.
> > >
> > > Feel free to start a thread on it. As above, I recommend
> > > one-key-per-client and running your own CA.
>
> I wouldn't recommend running your own CA because you will have to
> deploy a trust relationship with every client.
>
> > For secure connections you will have to set up CA and TLS keys with
> > any option.  Even ftps - unless the ftp server is already configured
> > with its TLS certificates.
>
> Or you use certificates from LetsEncrypt. Their CA is already trusted
> on most machines my default.

Thanks for mentioning this!  I had forgotten about LetsEncrypt ...  :-)

-- 
Regards,
Mick