Hi ondoho,

I will try to give answers to your post #

Yes, just follow the howtos on OpenVPN official documentation, and you will end up with an infrastructure relying on your self-signed CA.

Generally, you do not need any additional hardware, providing that you already have computers that can access Internet, and and at least one that is permanently connected to and reachable from Internet. It is on that particular computer that you will base your CA, and have it acts as the OpenVPN server. The others will run as OpenVPN clients.

Thanks for the link, and the basic strategy recommendation!

It looks to me like OpenVPN is a commercial product and that to have 9 simultaneous connections would require purchasing it. That's a deal killer for my home network already. So, perhaps Openswan could be a good alternative?

This strategy also seems like a single point of failure, which I do not like. Currently, my main server is a Debian computer serving as my router and nfs server (among other things). I have all of its functionality, including IP address, ssh keys, etc, duplicated on a replacement server. In case my main server fails, I physically swap in my replacement server and I'm up and running again. It's not an instant failover, but it's good enough for my purposes and relatively simple to maintain.

Setting up a drop in replacement server with OpenVPN seems problematic. Maybe not with Openswan?

I don't know...it seems like a lot of complication and effort for dubious benefits. I find it pretty easy to set up and maintain using ssh to log in from one computer to another on my home network. I honestly don't see any benefit there. Bluntly, I'm going to keep on using ssh to log into other computers in my home network even if I also set up some sort of VPN thing. My biggest security concern is that I'm using simplistic IP level security for nfs shares of my nfs root computers.

If there's a straightforward way to encrypt all traffic between all of my home computers initiated within the initrd environment, then great! Otherwise...I'm not sure.

Openswan might be more my speed, and it seems like it might be straightforward to set up since I'd be using it strictly within a simple LAN (so, no filtering or NAT to worry about).

http://www.enterprisenetworkingplane...-Your-Mind.htm

In my case, the router's shared subnet would be the entire internet, while each client's shared subnet would be only a dummy interface's ip address (different from the actual physical NIC's LAN address). It seems pretty straightforward for my computers which boot off of a local drive. I'm not sure whether the potential benefits are worthwhile in my usage case...but I can't gauge that before figuring out basically what I'm looking at.

This whole "one or the other" question is silly. When I need to connect to a production server, I set up a VPN to that network, and then log in using SSH. They are not choices, they are tools that complement one another.

According to https://openvpn.net/index.php/terms-of-use.html
It seems that they also sell something called "OpenVPN Access Server" which is proprietary. https://openvpn.net/index.php/access.../overview.html

That's running an encrypted SSH session inside an already encrypted VPN tunnel. I hear my laptop groaning (and it's not even turned on!) at the mention of running every packet twice through the encryption engine. SSH on a nonstandard port and with password authentication disallowed works fine for me. I get one or two hits per month from probes on that port, and those typically send some fragment of HTTP and disconnect immediately when the SSH server replies.

I do keep a VPN service running at home and connect through it as my default route when I'm away and using my laptop at some random WiFi hotspot. It works great for that.

I'm not talking open source vs proprietary, I'm talking freeware vs commercial. But I was just looking at the provided link and it's FAQ etc. That may have led me down the wrong path.

Okay, so I've decided to just leap in with one of my Debian Stable machines with:

I don't really know what I'm looking at exactly and how to get started (it would be nice to be able to search for openvpn without seeing hits about the OpenVPN Access Server or whatever also). But I figure I could start off experimenting with using the Network-Manager applet GUI (between computers which have network-manager, obviously)...then if I figure out a good potential use for it I can practice doing it via command line.

Or...ugh. Okay, I don't really care about using the network-manager GUI. I mean, I might use it for a laptop I'd be using on the go. But I'd rather do this stuff via command line and text config files etc. It's just easier for me to set up and maintain my computers that way...shake and bake with command line/copy/paste, rather than configuring junk manually via GUI like a windows monkey.

And I've rethought my overall strategy a bit. I figure all computers might as well access the Internet the normal way. As such, every shared "subnet" is actually just localhost. So, my main server/router keeps the same basic DHCP server and routing functionality it currently has, but it no longer accepts any connections to ssh or nfs on its physical network interfaces. It looks like the default is to share only localhost anyway, which suits my use case fine:

https://openvpn.net/index.php/open-s...ion/howto.html

So, this is getting more clear in my mind. Basic internet connectivity and LAN functionality remains the same, but I tighten up ssh and nfs so they only accept connections from within the VPN. My client computers auto-connect to the server via openvpn, which allows the clients to connect to the server's nfs shares and ssh access. I think that by default, I will need to ssh into the server and then from there ssh to other clients (I am okay with this). Generally, the clients will not be able to see each other.

...hmm. Okay, I will need to set things up so that the clients can directly see other clients. I use synergy to have the mouse/keyboard of one computer control many computers...

In any case, I just do not see any way around still using ssh. I will definitely still use ssh to give myself a remote command line interface. It works, and it works well, and I see no sensible way in which openvpn or any other VPN solution is a replacement for ssh. But I've got a lot of other stuff which I wouldn't mind tightening up...

I don't use gooey-tools to manage OpenVPN, so I can't speak to that. ("Real programmers don't need no stinkin' GUI ...") ;) ;)

But, basically, yes: you only expose OpenVPN to the outside world. You have no port-forwarding other than a UDP (not TCP/IP ...) port of your choosing. You specifically firewall-away any attempt to reach the outside world directly.

Now, your OpenVPN server will expose a virtual IP-address, on its software-produced utunX device ... (you are using OpenVPN in tunnel, not bridge mode) ... for itself: it should be 10.8.0.1. And you arrange for your sshd and so-on to "listen" only to that port for incoming connection requests. It does not listen to the outside world, and, even if it accidentally did, your home router will not "port-forward" anything for them to hear.

Every directly-connected external user will be assigned some IP-address on the 10.8.0.x subnet, and this is how the host communicates with them. (It's a configurable option whether you want the various clients to see and to be able to communicate with one another.)

So, your sshd, and anything else on your internal network that you wish to expose to your clients (via push route and a corresponding client-side pull ...), will be accessible only by first establishing a connection through your secret door.

:eek: If you are using a GUI, it is extremely important that you do n-o-t succumb to the temptation of "pre-shared keys == PSKs == passwords!" :eek: You must arrange things so that each and every authorized client has a uniquely-generated, one-of-a-kind, digital certificate, as does the server itself, and that it accepts no other form of identification. (If you use PSKs, you've basically thrown all of the possible goodness of any VPN right out the window ...)

Since I have never used the Gnome tool, I cannot speak for what it does.

However – in my blog, here, I do address OpenVPN in is several different ways, and "setting up the necessary files in the old-fashioned way" in this case just might be easier.

All crypto tools are engineered(!) to be obtuse, since they presume that you are Eve, not Alice or Bob. You will :banghead: against their very-deliberate obstacles – and I am a card-carrying testament to that fact(!) :) – but, really, only for a very little time.

If I firewall away any attempt to reach the outside world directly, how do I reach the outside world? This seems bizarre to me. For example, I regularly browse the internet. I also access Debian's software repositories to keep my computers up to date. I'm supposed to firewall away all this stuff? Why? To what benefit?

I looked through all four blog posts, and none of them seem to give any instructions on how to set this up, or link to instructions on how to set this up. This does not seem very helpful.

It sounds like you expect people to figure it out for themselves how to set it up, and that this is a feature rather than a flaw.

But I don't see it that way. I think that security depends upon giving adequate guidance on how to set things up without making mistakes. Those mistakes are an obvious risk for making security mistakes.

There are detailed straightforward instructions for how to set up ssh securely. I am quite happy with my passphrase protected key based ssh set on a custom port.

I am satisfied with the internet-facing security on my main server/router (straightforward iptables based security with only the custom ssh port and my web server ports open on the internet side). My interest in VPN is possibly tightening things up on the inside of my home LAN. It's not the "outside world" I'm so much concerned about. I'm more concerned about the various non-Debian devices within my LAN (such as Android phones).

The more obvious solution is something someone suggested earlier - set things up so that the WiFi access point is "outside" the trusted zone. Or set up a restricted guest WiFi. But these approaches make it difficult to make specific exceptions for various things, such as an Android app which lets the phone act as a remote control/keyboard/mouse via WiFi.

(Note that it's really hard to do nfs through an ssh tunnel because it likes to use a wide swathe of random ports. This is why it looks promising to me to have a solution which encrypts/routes all ports.)

+1

Security software which nobody can use does not provide security.


Sshfs?

I have found sshfs to be rather brittle compared to nfs. It's great for a short term connection, but it does not seem suitable for a long term connection.

I don't know how stable a VPN connection is for permanent connections, but I'd think it's pretty good since that's a common use case. And even if it goes down, it will be possible to reconnect it and the relevant nfs mounts will have simply sat around waiting for the connection to return. My experience with sshfs is that it's very sensitive to any sort of connection breakage.

That is not what a VPN is for, nor will it serve that purpose well. What you want is your WIFI network on a different subnet from your wired network, and consider it a DMZ with access to the internet but NO access into your internal wired network. If you have a WIFI only network device (printer?) you may have to add a SECURE wifi subnet and hard-code the IP (or make a reservation) for that device.

I have one rented VPS (at $7.99 month) which serves as OpenVPN server.

My regular home network has a Linux box which acts as internet router and OpenVPN router. That Linux box is connected to the VPN server.

I have a number of measurement/logging computers remotely installed (RasPi's) which are all connected to the OpenVPN server.

In my alternate home I also have a Linux box set up as OpenVPN gateway, and it is connected to the OpenVPN server.

On (all) my laptops I directly connect to the OpenVPN server.

The result:
I can transparently access any host on my both home networks from any other host.
I can access all the remote computers and laptops from wherever I am and the other way around.
Both home networks are behind the ISP router but I never need to deal with the ISP external IP address.
I have "no idea" how the network or firewall is configured for the remote measurement computers but I still can access them
The databases used by the remote measurement computers can only be accessed from the VPN. Which is easy for security measurement.
All in all, everything talks to each other like it is on the local LAN.

Routing of LANs through gateways is a bit tricky to find out. OpenVPN provides good HowTo's and it works.

There is just one security risk. The remote measurement computers could be stolen or unauthorized being accessed. Once a host is physically accessible its security is compromised and that host IS connected to the VPN and all the LANs. Now I don't store my private keys on those remote hosts, and on most hosts I have disabled password access. But I could have forgotten one. In any case, all hosts have their own key pair so I can easily withdraw a key on the OpenVPN server if I suspect something.

OpenVPN is FOSS, so license issues are none. And AFAIK using the self-generated certificates is secure. I need only to trust myself, hence I do not need a paid certificate.

jlinkels

I already have IP level security to handle my wifi connected laptops etc, and they do use static ip addresses. But I'm not sure what you mean by a "SECURE" wifi subnet.

Anyway, the more I think about it, the more tractable it seems. If I set up my two on-the-go laptops for VPN access, I might as well use the VPN access for when they're connected by WiFi also. Simpler that way, and more elegant. And if I do that, then why not set up all of my client computers that way? Okay, this is probably more trouble than it's worth for my nfs root computers, but I could actually convert all of them to RAMBOOT (loading a tarball from local drive rather).

Its not obvious how to set up VPN the "right" way, though, so I'm sitting on the idea and just thinking about it for now. I don't want to register anything with a third party as far as signing goes. And doing searches for getting started with OpenVPN are polluted with their commercial product. It's not obvious how to separate out that stuff for a newcomer. I dunno...maybe OpenSwan would be better. But I'm concerned that OpenSwan might be harder for me to access on-the-road.

In VPN parlance, "subnets" commonly refer to "remote subnets" ... portions of the internal network of a set of distant computers to which you have a secure connection, thereby allowing you to route traffic to and from them as though they were directly connected using some other kind of browser.

WiFi networks should be regarded as insecure since, basically, anyone can drive by your house and in a few minute's time figure out what your WPA2 password is. (And, in addition, you often go to a coffee-shop where, perhaps unbeknownst to you, everyone else in that shop is "on your local network" for the duration!) However, if your computers use other means to securely identify one another for sharing purposes, and do not allow a stranger to do anything, VPN within that network might be unnecessary. It's up to you.

No argument except with this: That part is not true. A "subnet" is a portion of the address space that may be addressed and routed differently than other parts of the network. It may be local or remote.

As an example, I use a full class C local and network (10.10.255.0/24, a subnet of the entire 10.* class A, itself a subnet of the larger ipv4 network space. From that I subnet 10.10.255.128/25 subnet for WIFI and use the lower 10.10.255.0/25 for direct wired network. There is no traffic allowed between these two local subnets, with one exception: a static route that allows all devices on both networks to reach my network printer.