📜 ⬆️ ⬇️

AmazonVPC IPsec bypassing standard tools

Introduction and conditions of the problem


We have an Amazon VPC with multiple subnets.
Inside the VPC is divided into several subnets.
Take two of them.
In the first (10.0.0.0/24 network), we call it net1, routing outwards is performed by the native Amazonian Internet Gateway, which is different for each subnet. You can bind Elastic IP to instances on this network and they will work.
The second (subnet 10.0.1.0/24), let it be net2 - a completely closed subnet, access from which to external resources is possible only through a separate instance with NAT configured on it (let's call it service). Direct access to this subnet from the outside, except through any instance from net1, will not work. The service itself also exists in net1.
Inside the VPC, the instances of both subnets see each other.
There is also an office network, even if it is called net0 (subnet 192.168.5.0/24).
There is a need to provide secure access from the office to the instances in net1 and back. This can be done in a native way for Amazon - using Virtual Private Gateway and its associated services. But there is one problem - routing is done through BGP, which is not and is not expected at the border router of the office. It has only pure IPsec with password authorization. In this situation, we must act through it.
The following implementation scheme comes to mind: at the service instance, which has access to the Internet and to all instances inside net1, and also has an Elastic IP, deploy an IPSec client, connect to an office router, and set up routing between networks.


Instance setup


I did not use the native instance that is supplied by Amazon, I didn’t use it as a gate, it was painfully cut off, so I installed Ubuntu.
In order for the server to perform its main function, it is necessary, in addition to the routing settings in the VPC control panel, to configure NAT on the instance.
In this case - masquerading.
This is done simply:
iptables -t nat -A POSTROUTING -o eth0 -s _vpc -j MASQUERADE
Now we need to install the ipsec utilities:
sudo aptitude install ipsec-tools
After installation is complete, you can begin to customize.
sudo nano /etc/ipsec.conf
For key authorization, the configuration is as follows:
 config setup nat_traversal=yes plutodebug="all" protostack=netkey conn home left=%defaultroute #    ,    leftsubnet=%net1_network% leftid=%instance_ip% leftnexthop=%vpc_gateway% right=%dst_ip% rightid=%dst_ip% rightsubnet=%dst_net% authby=secret ike=3des-sha1-modp1024 #       esp=3des-sha1-96 #     pfs=yes forceencaps=yes auto=start 

In the file /etc/ipsec.secret we write:
 %instance_ip% %dst_ip%: PSK "YOUR_AUTH_KEY" 


Where:
1.% net1_network% - subnet that you announce for access from net0. In my case, this is 10.0.1.0/24.
2.% instance_ip% - ip insansa service on which you configure all this.
3.% vpc_gateway% is the default router for your VPC. It is specified as the default route in the service instance routing table.
4.% dst_ip% - ip of the net0 router to which you will connect.
5.% dst_net% - office network announced for net1. In this case, 192.168.5.0/24.
')
Encryption algorithms set to taste, as you like.

Do not forget to change the NAT settings to the following in order to eliminate the tension on the direction we don’t need:
iptables -t nat -A POSTROUTING -o eth0 -s _vpc ! -d %dst_net% -j MASQUERADE
I will omit the setting of the second side, since everything is specific there depending on the piece of iron. My Asus is done quite simply in a completely visual mode in 2 minutes.

Thereafter
sudo /etc/init.d/ipsec restart
Everything should start.
If not, by the situation. A common problem is a mismatch of encryption.
In general, this is all that I wanted to tell.
Successful setting!

Source: https://habr.com/ru/post/148434/


All Articles