AWS VPN – Difference Between AWS Site-to-Site VPN and AWS Client VPN

amazon-web-servicessite-to-site-vpnvpn

I know that site-to-site is using IPSec (layer 3), but client is using TLS (application layer). It seems like both are actually site to site vpns after reading articles/ docs online.

I guess the protocol (IPSec vs TLS) is their only difference, which has implications on when you would use which one. I would guess that both are equally good, and you should always use TLS on the application layer anyway, even on top of client VPN.

How do you decide which one to use, and why?

Best Answer

In general the protocol doesn't have much to do with it. You can have IPSec tunnels in both site-to-site or client (aka road warrior) configurations, just like you can have OpenVPN (TLS) tunnels in both site-to-site or client setups. It's a matter of configuration and purpose, not the protocol used.

Site-to-Site VPN

typically 1-to-1 configurations
both sides in general have similar configuration
both sides have fixed IP address
either side can initiate or restart the connection
both typically have a network behind them (e.g. two office networks connected)
you can run a routing protocol (BGP, OSPF, ...) over the tunnel
the networks can communicate both ways

Client-to-Site VPN

typically N-to-1 configurations, with N clients connecting to 1 server
server and client configs are different
clients don't need fixed IP address
only clients initiate the connections (because the server doesn't know the client's current IP)
client is typically just a single laptop with no network behind it
routing only permits one IP per client, no BGP or OSPF supported
only client to the site behind the server connectivity is permitted, generally the site can't initiate connection to the client

That's roughly the difference between site to site and client to site VPNs.

In AWS the VPN Gateway uses IPsec protocol and the Client VPN uses OpenVPN protocol but that's just how AWS implemented the services. However in general it's perfectly possible to use either protocol in either setup.

Hope that helps :)

Related Solutions

Openvpn – ClearOS – how to create a site to site VPN between two ClearOS boxes

There is two different setup/install instructions on OpenVPN's site, standard howto and static key howto. Static key is only usable for a 2 machine setup.

You will want to follow the standard howto: http://openvpn.net/index.php/open-source/documentation/howto.html

Basically you will need 2 configuration files, 1 for the server, 1 for the clients. You will need to create certificates and keypairs for the server, and for all the clients, each client will need it's own certificate and a copy of the servers certificate. Also watch out for the pitfall of having the same "Subnet" for client LAN's and your servers LAN. The client will not be able to easily access the servers LAN if it is the same subnet like 192.168.1.x.

Feel free to leave comments on spots where you get stuck, been through this setup many times.

IPsec VPN – How to Configure ipsec.conf Files for Site-to-Site VPN

My word, you do have your work cut out. OK; here's a sort of outline primer, because at the moment you've got the fundamentals so wrong that the details don't matter.

Before anything else, the fact that you haven't got static public addresses for each of your internet connections is a problem. IPSec doesn't easily support tunnels in such configurations [1], so you're going to end up editing your ipsec.conf each time either of your addresses changes. OK?

Now, when I asked you if each OpenSWAN endpoint had a public IP address, and you confidently said "yes", it turns out - as I suspected - that you were wrong. Your ifconfig output shows me that one end has the address 192.168.1.78 and the other has the address 10.0.2.15. You also tell me that one end is (currently) behind the public IP address 212.251.112.115 and the other is behind 79.103.7.114. You don't say which is which, so I'll assume 192.168.1.78 is behind 212.251.112.115 and 10.0.2.15 is behind 79.103.7.114. If that's wrong, just reverse the correspondence. I'll also call the former pair left and the latter pair right. It makes no difference which is which, but it'll help us keep our thinking straight, which'd be a really good idea right about now.

You'll need to set up the public routers at both ends to forward UDP/500 and protocols 50 and 51 (just for completeness) to the OpenSWAN endpoints inside each public address. If you can't manage the two protocol punchthroughs, then investigate the doco on NAT traversal and forward UDP/4500 as well.

Firstly, it is a requirement that each end find its own IP address in the config, so that each end can know which of left and right it is when it starts. So left needs to have an ipsec.conf that contains

conn net-to-net  
    authby=secret
    left=192.168.1.78
    leftsubnet=192.168.1.0/24
    leftnexthop=%defaultroute
    right=79.103.7.114
    rightsubnet=10.0.2.0/24

and an ipsec.secrets that says

192.168.1.78 79.103.7.114: PSK "123"

while right must have an ipsec.conf that contains

conn net-to-net  
    authby=secret
    left=212.251.112.115
    leftsubnet=192.168.1.0/24
    right=10.0.2.15
    rightsubnet=10.0.2.0/24 
    rightnexthop=%defaultroute

and an ipsec.secrets that says

10.0.2.15 212.251.112.115: PSK "123"

Each end really needs to know who it really is, whilst it can pretend that it doesn't care that the remote end is behind a NAT. Do you see?

Furthermore, you'll need to config all the clients on each end so that they have a route to the remote RFC1918 network via the local OpenSWAN endpoint. You'll need to check that /proc/sys/net/ipv4/ip_forward is set to 1 on each endpoint. And it would be a really good idea to turn off any firewalling on the two endpoints, at least for now. You may also need to activate some config variables that tell each endpoint not to care that the remote endpoint thinks it has a different IP address from what the local endpoint thinks it has; from memory, these are leftid= and rightid=, but you're going to have to work that out for yourself.

So that's the basics. If you get the fundamental topology and concepts right, the rest is just debugging the details. Good luck with this.

[1] This isn't quite true. The SWAN implementations support opportunistic IPSec encryption, but this requires that you control your reverse DNS at both ends, and I'm guessing that you don't. Again, read the man pages if you want to know more about this.