[gentoo-user] Re: replacement for ftp?

[Kai Krakow]

Am Mon, 15 May 2017 08:53:15 +0100
schrieb Mick <michaelkintzios@×××××.com>:

> 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:
>  [...]
> > >
> > > 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.

I think most important is to use the UDP transport and not TCP, because
the tunnel protocol doesn't need to ensure packet delivery. This is
done by the protocols running inside the tunnel. Also, we usually
enable compression at least for low-bandwidth uplinks (which become
rare these days fortunately).

To compensate for the UDP protocol, we usually also give the tunneling
packets higher priority at the edge router to reduce drop rate under
uplink pressure.

This works well for most dial-up links we encounter (currently up to
100 MBit). I probably won't consider it for higher throughput links
because I fear the appliance CPU may become a bottleneck. But so far,
no problems, even not with CPU usage.


> > > 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.

I use IPsec only between to endpoints directly connected to the
internet (without NAT) and static IP. And only then it was really
reliable, and it performed well. No question about it...

And I like the fact that I don't need an intermediate transfer net as
opposed to OpenVPN.

OTOH, only OpenVPN has been reliable enough (and very reliable so far)
when one or both sides were NATed with dynamic IP.

And we had one customer running two networks across four sites, and
their IPsec solution never ran reliable. And this was with
professional, expensive firewall appliances. We replaced it with
site-2-site OpenVPN and it runs faster now and without any disconnects.
All sites use static IPs so that was never the problem. I don't know
what caused this. The old appliances were mostly blackboxes, and at
least one was faulty hardware (which explained problems at one site).


> > 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.

Oh wait... So I need to forward port 500 and 4500 so NAT-T does work
properly? Even when both sides are NATed? I never got that to work
reliably for one side NATed, and it never worked for both sides NATed.
And my research in support forums always said: That does not work...


>  [...]
> > >
> > > 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.

There are enough users that are overwhelmed with clicking anything else
than the browser symbol for network access, that this may be the only
sane solution even for two users. ;-)


> > >  [...]
> > >
>  [...]
>  [...]
> >
> > 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 ...  :-)

And don't forget to setup auto renewal... ;-)


-- 
Regards,
Kai

Replies to list-only preferred.