When connecting to cloud-based resources, enterprises need connectivity that is also secure. The most reliable and straightforward way to connect is use a secure tunnel for traffic traveling across the public internet.
A site-to-site IPsec VPN can act as a secure tunnel between your devices. You can ensure all traffic between the source and destination is encrypted, reducing threats of interception, packet sniffing, and unauthorized access.
Internet Protocol security (IPsec) uses cryptographic security services to protect communications over Internet Protocol (IP) networks. Using IPsec means you can add security you control to your network configuration, including: network-level peer authentication, access rules, and data encryption.
Why use IPsec site-to-site VPN connections?
Typically, networking pros trust private networks and distrust public cloud devices. Adding rules to sort traffic and isolate cloud traffic isn’t always enough though. If any service is compromised, you will want to restrict data center devices from gaining unauthorized access to devices in the data center and in the cloud.
One downside of cloud is that providers (aka CSPs) have absolute access to their own infrastructure, so they could theoretically access our servers and gain access to our private network. IPsec VPNs let you restrict the cloud-based server from being able to access our private network while still allowing the private network to connect to all of the services of a public cloud server.
Plus, intra-cloud traffic is not always encrypted. For example, in AWS traffic between instances in peered VPCs is not encrypted.
Build a site-to-site IPsec VPN with VNS3
Obviously we’re boasted but VNS3 offers IPsec VPN connectivity, plus acts as a firewall and enables more networking functions. VNS3 offers IPsec and NAT capabilities in one virtual instance/ AWS AMI. Rather than pile on services and cloud fees, VNS3 is one billable service — plus you can add in things like SSL termination, a proxy server, load balancing or content caching. More on that on our VNS3 product page.
So many options, so many connections!
Choose your own IPsec connection
VNS3 works well with most IPsec devices. So if you’ve got a Cisco ASA, Juniper, Fortinet, or similar device VNS3 can connect it to the cloud. If you’re a cloud-native type, you can also use VNS3 devices to create a site-to-site IPsec VPN in the cloud. Check out our post on connecting 2 or more VNS3 controllers over IPsec (coming soon!)
Choose your own encapsulation
You can use either NAT-Traversal encapsulation (over port UDP 4500) or Native IPsec for remote site-to-site VPN connection. VNS3 users can pick NAT-T if their connecting parties use NAT-T, so that VNS3 can detect if both ends and the tunnel support NAT-T.
VNS3 has a device-wide button to toggle between NAT-T or Native IPsec settings. If a topology requires both NAT-T and Native IPsec, you can peer 2 VNS3 Controllers together where one is NAT-T enabled, and the other is Native IPsec enabled.
Choose your own address scheme
When you use an IPsec VPN, you can choose to hide the internal IP addresses of the connecting devices. VNS3 lets you choose between the public IP address or private IP address, while the IP addresses remain hidden from each other and from the external users.
When making IPsec site-to-site VPN connections, telecom partners often require the encryption domain they connect to through VNS3 to use Public IPs as the encryption domain. Using public IPs as the remote encryption domains ensures no address overlap between internal and other remote connections. Check out our support topic on how to use public IPs for VNS3 encryption domains.
Follow all the Cohesive Networks stories on Medium and sign up to get our weekly RSS update delivered to your inbox!
Originally published at cohesive.net