As we all know AWS and Azure are the two Cloud providers and there can be possibilities that one of our services is running on one cloud provider and the other is running on another cloud provider and, both are dependent on each other.
Through this blog, I will guide you on the steps which will be needed for connecting AWS with Azure and also will be explaining all the components of both the cloud provider that will be required for creating the site-to-site VPN Connectivity.
Why are we trying to connect both?
In one of my projects, I met with a requirement where I was working on an application that follows a client-server architecture. There were servers connected to multiple clients. Initially, the Server was placed into AWS and the connected clients were also there, but after a couple of years our requirements got changed and a new business unit came into the picture with its own clients that were needed to be connected with the server present in the AWS cloud.
Now, these new clients were present on Azure but the server was on AWS. Migration of server was not an option for us because our customer was not ready to migrate those clients from Azure to AWS, so this was a completely new use case, to which we decided to connect both the cloud providers with each other by setting up IPSec VPN tunnel.
During this lockdown period, people are usually working from home which means they all are contributing to work by staying at home. So, if someone wants to work on something online, such as on a particular private or public server of a company, depending on the scenario, will need a network route to that server.
Meaning, they first need access to that particular server either via a public network or using VPN. These things have their own set of complexities. Therefore, we will discuss a few aspects of network access & their drawbacks:
VPNs are a great way to securely connect your private networks. They are even used to mask your public IP, so that you can access a public server without getting traced. There are a number of VPN offerings in the market ranging from open-source to proprietary software, self-managed to VPN-as-a-service, and with a huge range of features.
I recently got an assignment to get the best offering in the market. Best is a vague term. An Open-source VPN covering all the basic functionalities can be best for a simple implementation . Or a proprietary VPN having a lot of simplicity and customisation can be best for a medium or high budget implementation. So, I decided to compare different offerings in the market. Complete open-source VPNs are out of the scope.
Here are the things I kept in my mind before starting:
Let’s first talk about how it all started with and what we achieved.
It’s all started with a healthy discussion with a team where our team members were discussing many aspects of different fields of technology. So, one of our colleagues mentioned OpenVPN. So, we discussed the different working field, architecture, workflow of OpenVPN, in which role of iptables comes into the picture because for Linux architecture, OpenVPN support iptables as it’s primary firewall utility or can say OpenVPN support iptables as it’s a firewall for filtering workflow.
So in-between discussion, I mentioned that I am using iptables in OpenVPN to block traffic for the domain name and it is working fine. So, my colleague asked me about how you implemented & how is it possible to use iptables for domain and they discussed multiple logical explanations like OSI layer support and many other things. So, we decided to do POC of this discussion and try to write-up some blog or points to make clear that is it possible use iptables for the domain name and if not, what are the area that we can cover with iptables for the domain name and try to cover up flaws of this.
Continue reading “That’s Why Iptable Is Not A Good Fit For Domain Name?”