VPN 101 - Theory and real world application
Goal: Connect two remote networks together.
Problem: No physical circuit in place.
Resources: Typical internet connection.
Solution: A site-to-site VPN will let you use your existing internet to connect two networks together. Traffic is encrypted for privacy and security.
They configure their side.
???
Tunnel
You can now forward traffic from one network to the other.
The details
As I hinted; a VPN is a standardized solution that will create a private connection between two points. There are more advanced tunneling solutions out there, but this is about your 'regular ol' vpn'.
A virtual private network is typically used in these scenarios:
- Connecting a branch office back to HQ
- Connecting HQ to a DC colo you run
- Connecting a DC to the Cloud (AWS, Azure, GCP, etc)
- Connecting a Cloud network to another Cloud network (E.g., Azure vnet to AWS VPC)
- And more no doubt...
How does this play out in the real world? Well, after the decision to use a VPN is made, both parties will need to agree on all the VPN parameters. I'll explain those down below. Once you come to an agreement on the settings, typically documented in a colorful xls, you can both build your sides out. If you are the admin of both ends; this should be easy!
All that being said, let's be honest here. The majority of configuring a VPN is just learning how to communicate with the other end. Typically, if a VPN is having an issue getting established, it can be traced back to a mismatched setting. This is a situation where almost all of these settings just need to match each other. Use a document to track these for both ends, and be ready to troubleshoot. I'll go over that below as well.
Once both parties put in the right configs the fun can begin. Once the device has the configuration committed it will reach out to the other side. Some VPNs will let you specify Initiated/Receiver which do exactly that. Most are set to either can be the initiator.
The rest of the process can be broken up into two famous parts. IKE and IPSec. These are usually called Phase1 and Phase2. They both have their own specific settings.
BUT WAIT! One quick topic we need to cover first. Before you start doing anything, you need to decide if you are going to configure this as a route-based vpn or a policy-based vpn.
You need to pick one. You should pick route based if you like life.
Policy based: You create a policy that defines the tunnel. This most critically defines WHAT traffic to send to WHERE. E.g., On this VPN we allow network 10.1.0.0/24 talk to the other side's 172.16.1.0/24 network. This needs to be defined on BOTH sides in what Cisco calls a "Cryptomap". You cannot update one side without updating the other. They need to match. If traffic is routed, that matches that source and destination, it will be encrypted and sent over the tunnel. The tunnel will also STAY DOWN until interesting traffic has been routed through. This means to test the tunnel, you need to send interesting traffic first.
Route based: The VPN process creates a virtual interface. Tun1, Vpn1, st0, etc. This is a layer 3 interface with an INTERNAL routable IP on it. Any traffic routed through is encrypted or decrypted. That's it.
- You create the VPN
- It creates an interface
- Set a route 10.1.0.0/24 next-hop Tun1
- Traffic to 10.1.0.0/24 will be encrypted and routed to the other endpoint
BOTH SIDES DO NOT NEED TO MATCH! This means you can dynamically change what traffic is going across the VPN.
IKE - Internet Key Exchange - Phase 1
Exactly as the name implies. It's a key exchange mechanism over the internet. Once the two devices have started the VPN connection process the phase 1 configurations are compared.
"How do I tell you that I want to speak in pig-Latin without anyone hearing us"
Once the devices have contacted each other, they go through an automatic negotiation process to match settings. If they are able to match compatible settings they create a Security Association (SA). The SA will expire if a phase 2 tunnel is not created.
The big ones are:
- Do we use NAT traversal?
- Dead Peer Detection?
- Authentication algorithm
- Encryption algorithm
- SA Lifetime
- DH Key group
You can use defaults or specify on these. I suggest looking at your vendor's recommended settings to get these values. Once these match on both ends we start Phase 2.
Note on DPD: It's a mechanism used to detect if the connection has gone down. DPD will disconnect the VPN in that scenario. Hello packets sent from one end to the other. Other side responds. If no response is seen the tunnel will be forced down.)
Why do we want DPD in the real world? Imagine you have a [HQ] ---- [Branch] Hub/Spoke topology. They use crappy local internet and sometimes their internet will flap. A lot. To ensure redundancy we might have multiple circuits to this site. Shutting down DPD will terminate the routing path allowing the secondary link to take over routing. This ensures that traffic doesn't continue to be sent down a tunnel that has become unresponsive, and that a new path can be selected to ensure new traffic arrives.
IPSec - Phase 2
Pretty much the same, but we use the Phase 1 SA to secure the Phase 2 negotiations. Now we negotiate again creating a Phase 2 Security Association (SA) if settings match.
Phase 2 Settings example
- Protocol (ESP/AH)
- DH key group
- Encryption
- authentication
After Phase 2 is successful the VPN will be ready for use! You should see traffic flowing.
If you do not see the VPN connect, you should issue a reset. All vendors should have a reset mechanism. If not just toggle the peer address back and forth to restart the process. See below for some troubleshooting ideas if you have further issues.
TroubleShooting
Troubleshooting a VPN can be an artform. However, it mostly manifests as a test of patience. Of course troubleshooting a VPN can get fairly in the weeds, so I have a high level process you should at least start with.
-
Did it work previously? Woke up to the VPN down but no changes? Check the internet. If the internet works check any firewalls in between. Maybe the security guy was working late.
-
Tunnel won't come up? Chances are there is a mismatched value. Double check and try again. Verify you're using the correct peer public IP. If you don't find anything there you NEED to examine the logs. Don't be lazy here. Find the correct log, and find out why it's not working. It will absolutely tell. E.g., Juniper will give you a "mismatched configuration between the VPN devices" warning. This is a nice way to say CHECK THAT THE PASSWORDS MATCH YO!
But seriously. Get the log. It'll say "Negotiations failed because xyz setting" or "No negotiations found" which means you need to go back to the drawing board on the settings. -
How do I know if it's working? The tunnel should show some flavor of "Connected" or "UP". They should also come with an "encrypt/decrypt" counter. E.g., "Packets Encrypted: 500 Packets Decrypted: 500". If your numbers are at 0 you need to check the stack.
-
Can I manually reset the VPN? YES! Every vendor I've found (minus AWS - I have a trick for this) has a good mechanism to bring the VPN down and back up. This is like rebooting your old computer... it just fixes it sometimes.
Resources
Cisco ASA
https://www.packetswitch.co.uk/cisco-asa-site-to-site-vpn/
https://networklessons.com/cisco/asa-firewall/cisco-asa-site-site-ikev1-ipsec-vpn
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-firewalls/215884-configure-a-site-to-site-vpn-tunnel-with.html
Juniper SRX
https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-configuration-overview.html
https://help.zscaler.com/zia/ipsec-vpn-configuration-guide-juniper-srx-220
My Favorite -----> https://support.juniper.net/support/tools/vpnconfig/
Cloud
https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal