Setting up bridged connections for clients on a container running openvpn

Operating Systems & Open Source Linux
1

Hi my fellow linux people,

I'd like to set a VPN service within a home lab I have set up. Therefore, I have set up a container running CentOS7 and installed openVPN following a Digital Ocean article. However, near the end they suggest: "Next we'll add a rule to iptables to forward our routing to our OpenVPN subnet, and save this rule.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables-save > /etc/sysconfig/iptables

However, I don't want to set up NAT here, I'd like to bridge the connection so that I can access all of the other containers via VPN. I'm not totally sure how set up a bridged connection like this and am really struggling with the online documentation.

Does anyone have any suggestions?

2

OpenVPN has some pretty serious documentation on their site. Here's the page on bridging.

https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

But I'm not sure if you need that. If I understand correctly (and I may very well not), you've got a Digital Ocean account with multiple containers. Each container is on a subnet. Let's say 192.168.0.0/24 for sake of discussion. Your secure subnet is 10.8.0.0/24, so when a client connects to OpenVPN they get for example 10.8.0.6 as an IP address.

At this point any clients connecting to OpenVPN have access to the container that is hosting OpenVPN, but you can't communicate with any other containers, even if you use the iptables commands you mentioned. Yes?

The routing out of the OpenVPN container is probably working just fine, your other containers just don't know where to send their response to. So they send their response to the default gateway, which likely also does not know where to send packets for 10.8.0.0/24.

So your options here are to either add a static route at your default gateway, letting it know that any traffic intended for 10.8.0.0/24 should go to the IP address of your OpenVPN container. Or if you don't have access to the default gateway, you can setup a static route on each container.

I personally have not seen a bridged setup for OpenVPN. While I have been using OpenVPN for a number of years now, I'll admit I haven't tried much in the way of fancy configuration. I'd recommend you go with the NAT option unless you've got a solid reason to go bridging.

Edit:
To be clear, at the end of the NAT setup, you should be able to ping the Digital Ocean internal IP addresses of your containers from a given client machine. No fancy port forwarding or anything like that necessary. All too often when people think NAT they think port forwarding, but that's not always the case.

3

Basically, I have a subnetted lab with public facing services on my LAN. One of them is a VPN service running as a container on a proxmox box along with a websever. I'd like to be able to VPN into my network and work on the webserver from out of town. I'm thinking that if the VPN puts the clients on it's own subnet it won't be able to talk to the web server and then I'm on an empty subnet with nothing to ssh into...

Hopefully that clarifies my circumstances a little more.

4

Wow! This is really complicated!

5

Networking is complicated D:.

1 Like
6

Okay, perfect, I think I've got everything. This right here is a pretty common misconception with OpenVPN. Let me see if I can simplify it a little bit.

Let's say that your Lab Subnet is 192.168.100.0/24.
Now OpenVPN gives you an encrypted subnet, and in this case it's 10.8.0.0/24.
Your client machine, say your laptop, is at the local Starbuck's on 192.168.0.0/24.

Your client machine connects to OpenVPN and gets 10.8.0.6. But in your server's OpenVPN configuration file, you've got this line...

push "route 192.168.100.0 255.255.255.0"

That tells your client machine that it can use the OpenVPN server (as far as your client knows, it's 10.8.0.1) to reach the 192.168.100.0 network. Happy!

Because NAT and routing is enabled on your OpenVPN server, that server will handle all of the routing to and fro, but the key piece at this point is to make sure that the machines in your Lab Subnet know to direct traffic intended for 10.8.0.0/24 to your OpenVPN server. Otherwise your machines will get the traffic, but won't be able to respond and it will look like something is wrong with your OpenVPN setup, when really you have a routing problem.

That is why it's very very very important when you're troubleshooting to not assume that traffic isn't reaching your Lab Subnet just because your client isn't getting a response. Get a packet sniffer on a machine in your Lab Subnet, and verify whether or not packets from your client machine are actually hitting your Lab Subnet.

I worked with a network admin once who phrased it perfectly. A client would send her a Wireshark trace of what a server was receiving from a client PC and ask her to troubleshoot it. To which she would say, "Great, we've got what the server is receiving. But that's only half of the conversation. We need the other half."

Edit:
Also, to give another example. Here's a setup I have running right now, though the numbers have been changed to protect the innocent.

Work network: 192.168.0.0/24
Encrypted subnet: 10.254.254.0
My network: 192.168.15.0/24

I use my machine at 192.168.15.13 to connect to my work network's OpenVPN service. My machine gets 10.254.254.6. I can now open my browser and hit up an internal only web server at 192.168.0.150, or a printer at 192.168.0.75. All because of the OpenVPN configuration file pushing the route for 192.168.0.0/24 to me the client, and the default gateway on the work network knowing what server to route 10.254.254.0/24 traffic to.

Hopefully one of these giant blocks of texts helps to clear things up.

1 Like
7

Really thank you for that explanation. I think I know exactly what you're talking about in the config and I'll give it a shot sooner than later. However, I've run into another jam where I cannot connect becuase of this issue:

WARNING: No server certificate verification method has been enabled

Which is odd. I thought the cookbook I followed would have, let's say, done this correctly. So I'm going to have to google myself out of this mess first. That way I can proof of concept this --- then I'll redo server.conf file on the openvpn container.

I'm calling it a night though...

8

That warning probably isn't the issue, look for an error.

1 Like
9

For that warning I think you need this in your OpenVPN client configuration file.

ns-cert-type server

And then, of course, your OpenVPN's certificate needs to be a server certificate rather than a user certificate.

1 Like
10

Sun Apr 23 00:48:56 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Apr 23 00:48:56 2017 TLS Error: TLS handshake failed
Sun Apr 23 00:48:56 2017 SIGUSR1[soft,tls-error] received, process restarting

11

For that either disable TLS authentication or make sure both the client and sever are using the same TLS key

1 Like
12

So far I have the ca.crt, client.key, ta.key, and client.crt on both machines.

13

TLS authentication is probably misconfigured. either remove the tls-auth line from your client and server config files or make sure that the server has 'tls-auth /path/to/ta.key 0' and the client has 'tls-auth /path/to/ta.key 1' in the config, and make absolutely certain the the key is the same on both client and server, as it's essentially a pre-shared key.

1 Like
14

So much this. I had a client the other day fail to connect because there was an extra empty line at the bottom of ta.key, even after the ----- END OpenVPN Yadda Yadda ----- line.

1 Like
15

My ca.crt and ta.key are exactly the same on both, as far as the tls-auth /path/to/ta.key defaults for these are just "tls-auth ta.key" do I need full path those?

Example 

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
tls-auth ta.key 0 # This file is secret

Do I have to be explicit with the full path on those bad boys?

16

If they're in the same directory as the configuration file, no. But it never hurts to put the full path in, just remember to change it should the paths ever change.

Also, if you've got a configuration file on a Windows machine, like say a client machine, any full path is going to look funny, because you need to escape the \ in the path. So 

C:\\Program Files\\OpenVPN\\conf\\something\\something\\darkside
1 Like
17

I have nix on all these bad boys right now.

18

I'm wondering if my isp is blocking 1194 possibly, or I have really shitty internet connection and this is a very heavy handshake?

Nope don't think it's my ISP or connection - I can't get to in from in network on the same network - wow I suck at VPN.

I'm going to see if 1194 is open on the vpn server.

19

just remove the tls-auth lines and see if that works

1 Like
20

Man 1194 is closed on my machine and It's going to be damned to let me open it

PORT STATE SERVICE
1194/udp closed openvpn