Virtual Private Gateway (VGW)
- VPN concentrator on VPC side
- Max 5 per region
- Represents 2 distinct endpoints in separate data centers (AZs)
- Each endpoint in distinct AZ (no control which AZs)
- Two unique public IP addresses
- Redundancy
- Add second CGW that points to the same VGW
- This creates additional 2 tunnels (total 4 tunnels)
- No point in adding more VGW in the same VPC
- Terminates
- Hardware VPN connection
- Direct Connect
- Acts as ECMP route to the set of WAN routers (not Internet routers, compare with IGW)
Customer Gateway (CGW)
- Represents customer device in the VPN connection
- Customer-end router supporting IPSec termination
- This can be software solution
- Initiates the VPN connection
- Device may support static or dynamic routing
- Max 50 per region
AWS Hardware VPN
- Uses Virtual Private Gateway
- IPSec based
- Pre-shared key generated by AWS
- Uses tunnel mode (no policy based VPN)
- Customer Gateway must be able to terminate IPSec
- NAT Traversal (NAT-T) supported
- Uses UDP/4500 to encapsulate ESP packet
- Depends on "Internet weather" (latency, jitter)
- 1 VPN connection -> 1 VPC
- 1 VPC max 10 VPN connections
- Max 50 VPN Connections per region
- 5 VPC per region * 10 VPN connections each
- 2 endpoints (tunnels) in different AZs for HA
- Single customer endpoint at minimum
- You can maintain your on-premise private IP address (no NAT)
- Routing type
- Static
- Requires routes (IP prefixes) to be manually specifed
- Consolidate ACL's to cover all IPs
- Dynamic (preferred)
- Customer device must support single-hop BGP
- BGP based - announces routes to AWS
- AWS adds them to the route table in VPC, e.g.
- 192.168.0.0/16 -> VGW
- Route propagation
- Anything I receive on VGW via BGP: add to route table
- AWS adds them to the route table in VPC, e.g.
- Max-prefixes: 100
- 2 pr 4 byte AS (Autonomous System) number for both ends
- Can be changed on both ends
- Automatically generates BGP IP addresses (link local) for each end, e.g.
- Tunnel 1
- AWS: 169.254.169.1/30
- Customer: 169.254.169.2/30
- Tunnel 2
- AWS: 169.254.169.5/30
- Customer: 169.254.169.6/30
- Tunnel 1
- Static
- Connections are initiated by Customer Gateway
- on-premise router sees interesting traffic and initiates session to VGW
- Fragment IP packets before encryption
- Reason why there is no VGW<->VGW Hardware VPN
- Who would initiate
- Keepalive required to keep the tunnel up
- 1 unique IPSec Security Association (SA) pair per tunnel
- 1 inbound and 1 outbound
- Total: 2 unique pairs for 2 tunnels = 4 SA
- HA
- Use two customer gateway connections cross wired (i.e. 4 tunnels total)
- Routing on-premise to decide which one to use
- Use two customer gateway connections cross wired (i.e. 4 tunnels total)
Software VPN
- Run EC2 instance acting as VPN server ("Software VPN Appliance")
- OpenSwan - IPSec based
- OpenVPN - SSL based
- Commercial: Fortinet, Cisco, Check Point, Microsoft, Astaro
- Customer can manage both ends of VPN (unlike AWS Hardware VPN)
- Responsible for HA
SSL VPN
- Clientless
- Uses browser
- Non Web applications must use Java/ActiveX controls
- SSL used as tunnel to access internal application
- May use special "Portal" (Gateway)
- Layer 6/7
- Use cases:
- remote access
- roaming client
References
- https://technet.microsoft.com/en-us/library/cc737154(v=ws.10).aspx
- https://sc1.checkpoint.com/documents/R77/CP_R77_VPN_AdminGuide/13847.htm
- https://www.youtube.com/watch?v=SMvom9QjkPk&list=WL&index=49
- http://serverfault.com/questions/185635/what-is-the-difference-between-bgp-and-ospf
- http://searchsecurity.techtarget.com/feature/Tunnel-vision-Choosing-a-VPN-SSL-VPN-vs-IPSec-VPN
- https://www.youtube.com/watch?v=EqVpsnAen5I
