But, what if your cloud provider doesn’t offer managed services for site-to-site VPN connectivity? Or if the process for establishing site-to-site VPN connectivity using managed services<\/strong><\/a> requires different configurations and setup steps? Don’t worry, we’ll address those scenarios too.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n So, if you’ve ever had trouble with site-to-site VPN connections or making sure your networks connect properly, you’re in the right place. Let’s get started and understand site-to-site VPNs together!<\/p>\r\n\r\n\r\n\r\n Using StrongSwan for site-to-site VPN connectivity offers several advantages:<\/p>\r\n\r\n\r\n\r\n 1.Flexibility: StrongSwan is highly configurable, allowing you to tailor the VPN setup to your specific requirements and network environments.<\/p>\r\n\r\n\r\n\r\n 2. Open Source: Being an open-source solution<\/strong><\/a>, StrongSwan<\/strong> is cost-effective and offers transparency, enabling you to inspect and modify the code as needed.<\/p>\r\n\r\n\r\n\r\n 3. Compatibility: StrongSwan supports various VPN protocols, including IKEv1 and IKEv2, ensuring compatibility with a wide range of devices and platforms.<\/p>\r\n\r\n\r\n\r\n 4. Security: StrongSwan prioritizes security, offering robust encryption and authentication mechanisms to protect your data during transit.<\/p>\r\n\r\n\r\n\r\n 5. Ease of use: The ease of use is another significant benefit of using StrongSwan for site-to-site VPN connectivity. Whether you’re a seasoned network administrator or a novice user, StrongSwan provides a user-friendly experience, ensuring that you can efficiently establish and maintain secure site-to-site VPN connections between various cloud platforms<\/strong> and on-premise infrastructure<\/strong><\/a>.<\/p>\r\n\r\n\r\n\r\n I will demonstrate how to establish a site-to-site VPN connection between Azure<\/strong> and AWS<\/strong>. This method can be applied to any cloud platform or on-premise infrastructure. Step 1: Configure VPC, Subnet and Internet Gateway<\/strong><\/p>\r\n\r\n\r\n\r\n Create a Virtual Private Cloud<\/a> (VPC) with a non-overlapping CIDR block compared to the Azure VNet. Within the VPC, establish a public subnet and attach an Internet Gateway to enable connectivity to the internet. Create a public route table and configure a route allowing internet traffic flow through it. Associate the public subnet with the route table to facilitate proper routing. Finally, launch an EC2 instance<\/a> in the public subnet.<\/p>\r\n\r\n\r\n\r\n Step 2: Connect Securely to the EC2 Instance and Perform the Configuration<\/strong><\/p>\r\n\r\n\r\n\r\n A:<\/strong> Update the package repository and upgrade existing packages and install StrongSwan<\/strong><\/p>\r\n\r\n\r\n\r\n B<\/strong>. Generate a Pre-Shared Key (PSK) for authentication purposes on both endpoints of the VPN tunnel, execute the following command<\/strong>.<\/p>\r\n\r\n\r\n\r\n Copy the generated key and paste it into a secure location after removing any extra spaces.<\/p>\r\n\r\n\r\n\r\n C<\/strong>. Open the “ipsec.secrets” file and add text with below format:<\/strong><\/p>\r\n\r\n\r\n\r\n D. Access the “ipsec.conf” file and append the provided configuration to the end of the file. Save the changes and exit.<\/strong><\/p>\r\n\r\n\r\n\r\n E. Enable ip forwarding<\/strong><\/p>\r\n\r\n\r\n\r\n Enabling `net.ipv4.ip_forward=1<\/strong>` allows the instance to function as a router. With IP forwarding enabled on a Linux system, it gains the ability to forward packets between different network interfaces, similar to a router. StrongSwan relies on IP forwarding to efficiently route encrypted VPN traffic between the local and remote networks. Without IP forwarding enabled, the instance would not be able to effectively handle and route VPN traffic, leading to connectivity issues and potential VPN tunnel failures effectively.<\/p>\r\n\r\n\r\n\r\n To enable IP forwarding:<\/p>\r\n\r\n\r\n\r\n F. Source and destination check off<\/strong><\/p>\r\n\r\n\r\n\r\n By default, EC2 instances in AWS have a feature called “source\/destination check” enabled. This feature ensures that an instance only accepts traffic that is either destined for or originates from itself. This behavior is suitable for most instances that function as servers. However, when an instance acts as a router, such as when running StrongSwan for VPN connectivity, it needs to be able to forward traffic between different network interfaces, even if the traffic is not specifically destined for the instance itself. Disabling source and destination checks allows the instance to process and forward packets intended for other destinations. This can be done through the AWS Management Console by selecting the instance, navigating to its networking settings and disabling the source\/destination.<\/p>\r\n\r\n\r\n\r\n G.<\/strong> Configuring Route in the Public Route Table for Azure VNet:<\/strong><\/p>\r\n\r\n\r\n\r\n The purpose of adding this route is to ensure proper routing of traffic between the EC2 instance where StrongSwan is installed and the Azure Virtual Network (VNet). This step is essential for establishing a VPN connection between the two networks and facilitating the exchange of data securely.<\/p>\r\n\r\n\r\n\r\n To add the route, follow these steps:<\/strong><\/p>\r\n\r\n\r\n\r\n 1. In the “Destination<\/strong>” field, enter the CIDR block for the Azure VNet. This CIDR block specifies the range of IP addresses assigned to the Azure VNet.<\/p>\r\n\r\n\r\n\r\n 2. In the “Target<\/strong>” field, select “Instance<\/strong>” and then choose the EC2 instance ID<\/strong> of the server where StrongSwan is installed. This indicates that the specified destination CIDR block should be reachable via the selected EC2 instance.<\/p>\r\n\r\n\r\n\r\n Routing VPN Traffic:<\/strong><\/p>\r\n\r\n\r\n\r\n Once the route is added, the EC2 instance hosting StrongSwan effectively handles the VPN connection and forwards the traffic through the VPN tunnel to the Azure VNet. This ensures seamless communication between the two networks and enables secure data exchange over the VPN connection.<\/p>\r\n\r\n\r\n\r\n Step 1: <\/strong>Configure Azure Environment for StrongSwan Deployment<\/strong><\/p>\r\n\r\n\r\n\r\n Now, for Azure, create a resource group and within it, deploy a Virtual Network (VNet) with associated subnets. Ensure proper internet connectivity by configuring the subnet where the virtual machine (VM) hosting StrongSwan will be launched. This includes setting up appropriate routes to allow necessary traffic flow. Finally, launch the virtual machine within the specified subnet.<\/p>\r\n\r\n\r\n\r\n Step 2: Connect Securely to the Virtual Machine and Perform the Configuration<\/strong><\/p>\r\n\r\n\r\n\r\n A:<\/strong> Update the package repository and upgrade existing packages and install StrongSwan<\/strong><\/p>\r\n\r\n\r\n\r\n B<\/strong>. Open the “ipsec.secrets” file and add text with below format:<\/strong><\/p>\r\n\r\n\r\n\r\n Ensure that you replace the placeholders with the correct IP addresses and VPC CIDRs.<\/p>\r\n\r\n\r\n\r\n D. Enable IP forwarding<\/strong><\/p>\r\n\r\n\r\n\r\n As mentioned previously, navigate to To enable IP forwarding, access the network settings of the launched StrongSwan virtual machine. Navigate to the IP configuration section and enable the option for IP forwarding by checking the corresponding box.<\/p>\r\n\r\n\r\n\r\n E. Add route<\/strong><\/p>\r\n\r\n\r\n\r\n To add a route in the default routes of an Azure VM, first, create a route table. Then, navigate to the routes section within the route table. Create a new route, selecting “IP address” as the destination type. Specify the CIDR range of the AWS VPC previously created as the destination CIDR range. Choose “Virtual Appliance” as the next hop type and provide the private IP address of the StrongSwan Azure VM as the next hop address. Lastly, make sure to associate the subnet to the route table.<\/p>\r\n\r\n\r\n\r\n By specifying the destination as the AWS VPC’s CIDR range and setting the next hop as the StrongSwan Azure VM’s private IP address, we ensure that traffic intended for the AWS VPC is routed through the VPN tunnel established by StrongSwan.<\/p>\r\n\r\n\r\n\r\n \u00a0You are all set, now go to your AWS and Azure VM and run the below command on by one.<\/p>\r\n\r\n\r\n\r\n Once the VPN tunnel has been successfully established, all resources within your Virtual Network (VNet) will become capable of communicating with each other. To verify connectivity, you can create instances in both virtual private networks, each within different subnets. These instances should be able to communicate via their private IP addresses.<\/p>\r\n\r\n\r\n\r\n To verify connectivity, execute the following commands:<\/p>\r\n\r\n\r\n\r\n Replace `<private IP of Site A>` and `<private IP of Site B>` with the actual private IP addresses of the servers in Site A (AWS) and Site B (Azure), respectively. These commands will test connectivity between the servers in both sites.<\/p>\r\n\r\n\r\n\r\n In conclusion, we have successfully set up a site-to-site IPsec VPN connection between Azure and AWS using the open-source tool StrongSwan. By leveraging StrongSwan instead of managed services provided by cloud providers, we were able to save costs while maintaining a high level of security and flexibility.<\/p>\r\n\r\n\r\n\r\n The ease of setup and configuration provided by StrongSwan allowed us to establish the VPN connection in a relatively short amount of time, ensuring minimal disruption to our operations. Additionally, the compatibility of StrongSwan with various VPN protocols and platforms made it a versatile choice for our deployment needs.<\/p>\r\n\r\n\r\n\r\n By implementing IP forwarding and configuring route tables on both cloud platforms, we ensured proper routing of traffic through the VPN tunnel, facilitating seamless communication between the networks. This setup not only met our security requirements but also provided a reliable and efficient means of data exchange between our cloud environments.<\/p>\r\n\r\n\r\n\r\n Moreover, it’s worth noting that StrongSwan is not limited to specific cloud platforms; it can be deployed on any cloud platform or even on-premise infrastructure, making it a universally applicable solution for establishing secure VPN connections.<\/p>\r\n\r\n\r\n\r\n In summary, by opting for an open-source solution like StrongSwan,<\/strong><\/a> we achieved a cost-effective, secure and easily manageable site-to-site VPN connectivity solution tailored to our specific needs. This experience underscores the importance of exploring alternative tools and approaches to meet infrastructure requirements effectively in any environment.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\nWhy Use StrongSwan?<\/strong><\/h2>\r\n\r\n\r\n\r\n
Steps To Create Site to Site VPN Connection Using StrongSwan<\/h2>\r\n\r\n\r\n\r\n
![\"\"](\"https:\/\/blog.opstree.com\/wp-content\/uploads\/2024\/03\/image-19-1024x341.png\")
<\/p>\r\n\r\n\r\n\r\n\r\n\r\nConfiguration on AWS side<\/strong><\/h2>\r\n\r\n\r\n\r\n
\r\n
\u00a0\u00a0\u00a0sudo apt update && sudo apt upgrade -y
sudo apt install strongswan -y<\/code><\/pre>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\nopenssl rand -base64 64<\/code><\/pre>\r\n\r\n\r\n\r\n\r\n\r\nsudo nano \/etc\/ipsec.secrets
<public ip of aws VM (site a)> <public ip of azure VM (site b)>: <encryption method> <key><\/code><\/pre>\r\n\r\n\r\n\r\n\r\n\r\nsudo\u00a0nano \/etc\/ipsec.conf<\/code><\/pre>\r\n\r\n\r\n\r\nconfig setup
charondebug=\"all\"
uniqueids=yes
strictcrlpolicy=no
# connection to siteA datacenter
<\/strong>conn siteA-to-siteB
authby=secret
left=%defaultroute
leftid=<public ip of site A>
leftsubnet=<vpc range of strongswan instance at site A>
right=<public ip of site B>
rightsubnet=<vpc range of strongswan instance at site B>
ike=aes256-sha2_256-modp1024!
esp=aes256-sha2_256!
keyingtries=0
ikelifetime=1h
lifetime=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=start<\/code><\/pre>\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\/etc\/sysctl.conf<\/code> file for editing.<\/li>\r\n\r\n\r\n\r\n#net.ipv4.ip_forward=1<\/code> and remove the #<\/code> at the beginning.<\/li>\r\n\r\n\r\n\r\nsudo sysctl -p<\/code>.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n\r\n\r\n![](\"https:\/\/lh7-us.googleusercontent.com\/fiSvSFbDCPShpfyq3cMwQdfBxioQlWGwJu8qxrAMXpr7cVPqmPFpAgSZNkLTyZqAiE2tZIBU5PAGfS6BdRAaHdDQskYKzdvwot9wIsiwSUDnrUyJmTyDCIKfMBDGkejSsARXZk2HeWoU04_jr9J7FH4\")
![](\"https:\/\/lh7-us.googleusercontent.com\/pz8US4MytP7JG-JItO51Q_5YxMls7QsjC2rA1hhCdeOLhegNuDZ-NiZ2AywzAyt7haQH24sUG2FVt0X4cYWQ1okc62OnrG5FEGfIT15Zzsy85dSdfWmahcW9FcbTOrwpatCdNAPOqfVSuEUYpKgFsHg\")
![](\"https:\/\/lh7-us.googleusercontent.com\/n8Twu0qCc4jDNxZWcXXZ8WyJzuiXlOKw4Au7G1YNq_7C48w-mFCvC6FbB_yzWndAxZIrKAukOZXqJlz-VErLen4mZ4JyZplAnQcBeL_jxat_rU_cg9yiBBMeVSTIXksGsHTh2F7sdWIlZuSKO4BKlx4\")
Configuration on Azure side<\/strong><\/h2>\r\n\r\n\r\n\r\n
\r\n
\u00a0\u00a0\u00a0sudo apt update && sudo apt upgrade -y
sudo apt install strongswan -y<\/code><\/pre>\r\n\r\n\r\n\r\nsudo nano \/etc\/ipsec.secrets
<public ip of azure VM (site b)> <public ip of aws VM(site a)> : <encryption method> <key><\/code><\/pre>\r\n<\/div><\/div>\r\n\r\n\r\n\r\n![](\"https:\/\/lh7-us.googleusercontent.com\/6u2i53h30RfvfapD0COI8VaD-LAdfqWfraZWabNtU7NRCAJ1FBXY10SWFl7h5NjjJlghcTYcdlOsdMry9HKbw_5ylM7vuxqvbfyECGQQnc3z9ym0yUp1Z7iRKCofoosoK5dXlPF7Zg8oQLvjdY9p2bA\")
C<\/strong>. Access the “ipsec.conf<\/strong>“ file and append the provided configuration to the end of the file. Save the changes and exit.<\/strong><\/p>\r\n\r\n\r\n\r\nconfig setup
charondebug=\"all\"
uniqueids=yes
strictcrlpolicy=no
# connection to siteB datacenter
<\/strong>conn siteA-to-siteB
authby=secret
left=%defaultroute
leftid=<public ip of site B>
leftsubnet=<vpc range of strongswan instance at site B>
right=<public ip of site A>
rightsubnet=<vpc range of strongswan instance at site A>
ike=aes256-sha2_256-modp1024!
esp=aes256-sha2_256!
keyingtries=0
ikelifetime=1h
lifetime=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=start<\/code><\/pre>\r\n\r\n\r\n\r\n\/etc\/sysctl.conf<\/strong><\/code> and uncomment the line net.ipv4.ip_forward=1<\/strong><\/code>. Save the changes. To apply the modifications without rebooting, execute the sudo sysctl -p<\/strong> <\/code>command on azure VM.<\/p>\r\n\r\n\r\n\r\n![](\"https:\/\/lh7-us.googleusercontent.com\/4NPzNUmXBhoHCBDjh7UZF1ElHLhhgWflRziZ80KzvOJP1ZiFuNM-OLBgSssE8KH2TX-uhnMluAgh-AysZWop4zKbtQGz_9PKVbk7B8uADwkSsTOebgMdZKapwLqjcRiJ23OVKUZb1sFsZntezTjGYHU\")
![](\"https:\/\/lh7-us.googleusercontent.com\/cKBfsHhpj3-KsVVLBT-Kb0TcwaCh8QiRNoDNpwh0YDattc8f7i4qi7QUSABH3D3lasSDa2SdSGxQ9niPnyh-TgDMZ7yUZdNlR5fGkrkXiEEyYD-jT3aThNNBipZ3qKqzpWD44qG-ySsZRwnSeunTd_A\")
![](\"https:\/\/lh7-us.googleusercontent.com\/SEzy8Q1kc9yBJMaFmudiSpTmjsH8OD4LqI0CtNpoKXjFxlgiflTgx6YMpA2t8NzlZjeHf1JUcSBmyR54uw0HURmdZgY6d4U2RlRt7wdErbcpiejSvj2Trof7prYmCfk4T_Gv0EaGutJRtPOzyquwNNc\")
That’s It ! Restart the Strongswan Service<\/strong><\/h2>\r\n\r\n\r\n\r\n
ipsec restart\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0
ipsec status\u00a0<\/code><\/pre>\r\n\r\n\r\n\r\n![](\"https:\/\/lh7-us.googleusercontent.com\/Gg6-XejJYmU3M5wx45ichm9UWTlIreYjG1ROVZ909G4lb9nc7B0kUps7UCi4VwfEQ_597Gwr8D5DA0yoWkOREwYLLcPgP1YYqqo6tz2mE99wXYU0M066jtqyYKUkD4f8Co4FOa3qUUHfjHyMJwKlY44\")
![](\"https:\/\/lh7-us.googleusercontent.com\/IO9etdP1TZPv0dmFlbSvBDxk5tPxDblz5aDBpE4MXq2D1SC1jst4QRvbV6PtMaMKpFSg8vVqn86AimuqTyI-4_KGftxxaxGj07bVu43Wxx-YcnZEftCgug6hbMfoTA_IOogB0WU6PcYYWcWqCRygl8Q\")
Verification<\/strong><\/h2>\r\n\r\n\r\n\r\n
ping <private IP of Site A>
ping <private IP of Site B><\/code><\/pre>\r\n\r\n\r\n\r\n![](\"https:\/\/lh7-us.googleusercontent.com\/m6fq5cY_tV1eZZgA2Egft1cBxdIWLaTSY9Id7sMXh6mvNhegBSbHwQR5wsSIsvmozu2cRzk2lcDQazAA9cDmVXpZryl6OEWRAciFfpV6OCCwI3KgJg843hZFW0U9wmtLbPGaODETsLeVLW4Tbu1EnDA\")
![](\"https:\/\/lh7-us.googleusercontent.com\/shBybRPX_dQ9N0a9hfEIs9KUFeMLU7bjuyz5nKZJeoYNOhzuaYTijeAodmkzsdE1LaV2-FA168xdpcoeyZeBCGx6msOGojHj1IqaXoy7FyRk5tIfhC2vRz_rVGH-NyKAs_HeRwpKLwFZOCG3fnFfnQk\")
Conclusion<\/h2>\r\n\r\n\r\n\r\n