Am Sun, 14 May 2017 09:52:41 +0100 schrieb Mick <michaelkintz...@gmail.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. > and also because unlike > IKE/IPSec it operates in userspace, not in kernelspace. IPsec also doesn't work without help from userspace processes. 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. > If you have > more than one client connecting to the server at the same time you > will need to set up multiple instances with different ports or > different protocols. That is not true: We connect many clients to the same server port without problems, each with their own certificate. > With IKE/IPSec you don't. MSWindows PCs come > with IKEv2 natively so they can be configured to use it without > installing additional client applications. IPsec can be a big pita if NAT is involved. For Windows client, L2TP may be a good alternative. > [...] > > > > > > 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. > [...] > > > > > > 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. -- Regards, Kai Replies to list-only preferred.
pgpoaF9L6wIsl.pgp
Description: Digitale Signatur von OpenPGP
