Double VPN || 2 Hop VPN || VPN-over-VPN

[Bebop]

As the title says: DoubleVPN || 2Hop || DoubleHop, I'm not sure if there is a specific phrase to use so I just included 3 (to get this thread in the forum search results for future if anyone is curious as I am now).




What is the required theory to understand before the above idea can be effectively implemented? What do I mean by that? I mean what is the basic framework? Can we have OPenVPN on both servers? Can we have OPenVPN on just the one server, whilst the other server is simply an IPTABLES forwarding implementation? Maybe OpenVPN over IPSEC?

Assuming:

• Both VPN servers are Centos or Debian Linux systems with OpenVPN and Bind9 installed.

Goals:

• User Authentication at server 1
• No decryption of network traffic until server 2
• DNS resolver at server 2
• Server 1 can know who is connected at any time, but can not know the contents of data streams
• Server 2 does not know who is connected (it just knows Server 1 is connected), but it does know the contents of the data streams (since it is the end-point, decryption occurs and therefore stream is revealed)

With those goals in mind, is it possible to explain a framework which might be the most appropriate in implementing such an idea? (however unoriginal the idea may or may not be, the info already out-there on how to implement it, is just not jumping out at me).

To address in advance the inevitable question of why, if possible it would be great to deal with the if and how first -- and then later deal on with the why and maybe look at potential alternatives. Any and all help very much appreciated.

[krzee]

I have decided to call this type of setup VPNchains
yes it can be done
http://secure-computing.net/wiki/index. ... /VpnChains
but I choose not to support it.
In the above link, there is another link with all the information which you need to understand in order to do it.
If you fully understand the info there, you'll figure it out =]
also, servers cant connect to eachother, but you could connect those 2 boxes by a client on one or the other

[Bebop]

I have decided to call this type of setup VPNchains
yes it can be done
http://secure-computing.net/wiki/index. ... /VpnChains
[...]

Thanks krzee! Appreciated.

I am looking into the guide/link now..

[Bebop]

In the VPN chain any machine can inspect traffic by sniffing the tun interface, so if one is compromised the traffic is also compromised. When I add this second VPN on top of the first, the whole chain becomes another untrusted network

Possible to implement the same setup in a different way so that traffic at the 1st hop in the chain is not decrypted by tun, as per:

Goals:

• No decryption of network traffic until server 2

?

Also I will keep in mind that you mentioned "chose not to support it", so the question is open to all-comers.

[krzee]

Possible to implement the same setup in a different way so that traffic at the 1st hop in the chain is not decrypted by tun, as per:
Goals:

• No decryption of network traffic until server 2

yes and no...
if you read my vpnchains link carefully you would see the write-up is all about what i found when running a vpn on top of the vpnchain (so the links in the middle see nothing)
so on the inner vpn, the answer is no
on the outter vpn, the answer is yes
route your traffic appropriately...

i dont mind answering general questions like this, i just dont feel like directing people on this type of setup (but all info you need to understand is in vpnchains writeup / my routing document that vpnchains writeup links to)

[Bebop]

when running a vpn on top of the vpnchain (so the links in the middle see nothing)
so on the inner vpn, the answer is no
on the outter vpn, the answer is yes
route your traffic appropriately...

Oh thank you once again. Its on the complicated side, but definitely something I am comprehending now. A quick demo of my understanding so far (or lack-there-of :p ):

--------------=side note=-------------------
Your guide on chaining has serverA, clientA, serverB, clientB. I am thinking it be possible to get the desired goal of no-decryption-at-serverA with the following setup, just using serverA and serverB (which I have labeled as VPN1 and VPN2). Its for situations where you don't have access to 4 or even 3 servers -- just the 2.
---------------------------------------------

Step 1:
Home PC <--===--> VPN1 <--===--> VPN2

Step 2:
Home PC <--================--> VPN2 <--===--> Internet

• Step 1a: Setup VPN2 as OpenVPN server
• Step 1b: Setup VPN1 as OpenVPN client and connect it to VPN2
• Step 1c: Setup VPN1 as OpenVPN server
• Step 1d: Setup Home PC as OpenVPN client and connect it to VPN1

• Step 2a: Setup VPN2 as OpenVPN server again (on new subnet) with routing to internet
• Step 2b: Setup Home PC as openVPN client again and connect to VPN2 (with an encrypted line all the way through VPN1) and out to internet.

[Bebop]

Physical Server 1 and Physical Server 2 are references to actual dedicated web servers (so a total of 2).

VPN Server 1, VPN Server 2, VPN Server 3, VPN Client 1 -- are references to instances of OPenVPN.




A more accurate depiction of the way in which Home PC connects with VPN Server 3:

[Bebop]

After another look over Krzee's guide, it appears that I've yet another refinement to make. With 2 instances of OpenVPN per server, I was not creating a chain which is scale-friendly.



My original idea:


And, new improved idea after looking at what Krzee has done:

[Edit] My original idea was better. In this 2nd idea, the client in the middle cannot (at least theoretically) connect to both servers at the same time -- since when it connects to the first one, it loses its route to the second one (the route being the www).
[Re-Edit] 2nd idea maybe not so bad, since route is not lost if route is not pushed by either of the servers with "redirect gateway".

Now for one last problem to solve. Is it possible for The laptop/homePC to not have to initiate two instances of OpenVPN client. Immediate answer looks like no!

[krzee]

the answer to the last problem depends on if you want to trust the machine in the middle

[Bebop]

A detailed view of the new model:



Hopefully this chapter is drawing to a solution now.

Still a minor road block in the way, which entails that pings are not yet getting to the countryB/Tun0 device.

More updates to follow.

[Bebop]

update:


Looks like I've nearly got it now.



The push-reset is necessary so that 10.77.2.6 does not redirect its gateway. Only the home clients should be redirected.

The last problem remains -- when I connect the 2nd VPN, I can no longer ping to 10.77.2.1 from the home pc. Some more messing with config and it should be ready.
---------------------------------
Solved. Full update will be posted soon. If anyone is interested in proper nested OpenVPN, using 2 linux servers and a Windows 7 desktop, then keep your eye on this here space.

[Bebop]

*Update*

As per request via PM, I will post my findings.

The above setups can generally work. However there are problems with MTU and fragmentation. If you have followed the diagrams posted above, and you would like to complete the setup to get it working, follow these final steps:

[1] Don't use --> push "redirect gateway def1" on any of your server instances. In fact, just don't push anything. Instead, we will use environment variables from the client.

[2] Add the following lines to your first client config (what do I mean by first client config? I mean -- your PC that you connect from at home will have 2 client instances of openVPN. The first client instance connects to the first hop at country A, the second client instance connects to the second hop at country B)

1st client config:

Code: Select all

client
dev tun
proto udp
remote COUNTRY_A_IP 1194
route-nopull
route remote_host 255.255.255.255 net_gateway
route 10.77.2.1 255.255.255.255 10.77.1.1

2nd client config:

Code: Select all

client                                
dev tun                               
proto udp                             
remote 10.77.2.1 1194            
route 0.0.0.0 128.0.0.0 10.77.2.1     
route 128.0.0.0 128.0.0.0 10.77.2.1

each client config will not be complete with the above code. You have to add the rest of the junk such as:

Code: Select all

nobind                                
persist-key                           
persist-tun                           
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3
ping 10
ping-restart 60

but that will be largely dependent on your own needs, so just modify it as you will.

Due to MTU and fragmentation problems, I have dropped the pursuit of the above method. If OpenVPN allowed a server instance to set "per client" MTU then it would be no problem, since it would be possible to have a larger MTU for the outer layer of tunnel and smaller for the inner.

Consider all of the above frameworks to be abandoned by me, and the framework in the next post to be the most appropriate for the desired outcome as per OP.

[Bebop]

Working Model that Works:

[Douglas]

I've bookmarked this thread. I'll need it in the future.