Set up VGW on AWS with OpenSwan

openswan-aws.md

Set up VGW on AWS with OpenSwan

You will need 2 VPCs. The Internet VPC will have the Internet Gateway and the OpenSwan EC2 instance. The Project VPC will have your application or Kubernetes cluster.

Internet VPC

• VPC CIDR: 10.230.30.0/24
• Private Subnet: 10.230.30.128/25 - Route Table with 0.0.0.0/0 to NAT
• Public Subnet: 10.230.30.0/25 - Route Table with 0.0.0.0/0 to IGW, 10.224.36.0/23 to OpenSwan Instance
• NAT Gateway in the public subnet with an IP of 52.15.61.171
• IGW attached to the VPN

Project VPC

• VPC CIDE: 10.224.36.0/23
• Private Subnets: Any - Route Table with 0.0.0.0/0 to NAT
• Public Subnets: Any - Route Table with 0.0.0.0/0 to VGW
• Customer Gateway to NAT in Internet VPC: 52.15.61.171
• VPN Connection with static route of: 0.0.0.0/0

Once the VPN Connection is active, download the configuration for OpenSwan.

Jumpbox

Launch an Amazon Linux 1 AMI in the public subnet of the Internet VPC, make sure it gets a public IP. You'll need to enable Auto-Assign IP for the subnet. Make sure you can SSH into the instance. Security Group - Inbound: SSH in from your IP. Security Group - Outbound: All

Project Server

Launch an Amazon Linux 1 AMI in the public subnet of the Project VPC.

• Security Group - Inbound: SSH in from your Internet VPC: 10.230.30.0/24
• Security Group - Outbound: All

OpenSwan

Launch an Amazon Linux 1 AMI in the private subnet of the Internet VPC.

• Security Group - Inbound: SSH in from your Internet VPC: 10.230.30.0/24
• Security Group - Outbound: All
• Disable Source/Destination Check in AWS

# SSH into the Jumpbox. Then SSH into the OpenSwan Server.

# Install OpenSwan.
sudo yum install openswan

# Follow the instructions from the downloaded config.

# Open the config file.
sudo nano /etc/sysctl.conf
# Ensure these values match:
# net.ipv4.ip_forward = 1
# net.ipv4.conf.default.rp_filter = 0
# net.ipv4.conf.default.accept_source_route = 0

# Apply the changes.
sudo sysctl -p

# Restart the network services.
sudo service network restart

# Open the ipsec config file.
sudo nano /etc/ipsec.conf
# Uncomment the line at the bottom.
# include /etc/ipsec.d/*.conf

# Create a new config file.
sudo nano /etc/ipsec.d/aws.conf
# Paste in the contents from the downloaded config.
# Replace leftsubnet=<LOCAL NETWORK> with leftsubnet=0.0.0.0/0
# Replace rightsubnet=<REMOTE NETWORK> with rightsubnet=10.224.36.0/23 (Project VPC CIDR)

# Create a new secret file.
sudo nano /etc/ipsec.d/aws.secrets
# Paste in the contents from the downloaded config.

# Start the ipsec service.
sudo service ipsec start

# Check the logs.
sudo service ipsec status
sudo ipsec auto --status

# The tunnel in the VPC connection in AWS should now be "up".

You can now access the Project Server from any server in the Internet VPC. The Project Server can also access the internet because it's routing through the OpenSwan server.

Resources

• https://hackernoon.com/setup-raspberry-pi-3-as-aws-vpn-customer-gateway-7432f653707
• https://blog.theodo.fr/2018/01/setup-software-vpn-aws-platform-third-party-corporate-network/

Gotta laugh - was on Amazon Linux 2 and couldn't figure out the problem. So went to Amazon Linux 1 and did it all again. Only THEN did I find this!

Thanks

https://kloudvm.com/aws/aws-site-to-site-vpn-using-openswan-ipsec-step-by-step-tutorial/

https://kloudvm.com/aws/aws-site-to-site-vpn-using-openswan-ipsec-step-by-step-tutorial/

Great, thanks for putting an article around it!

First of all - appreciate the detailed notes.

I have made in total of 8 attempts with this lab. However, I just couldn't make the tunnel up with openswan on linux. On the other hand, I was following cloud guru Adv Network course. I was able to make the tunnel up with windows server. I am using AWS Linux 2 and openswan 3.25.

One observation:
Failed to add connection "Tunnel1", esp="aes128-sha1;modp1024" is invalid: ESP encryption algorithm 'aes' is not supported

If anyone has any clue, please share with me.

Been doing a similar lab and ran into the 'encryption algorithm' error as well. Stuggled a lot to get it to work, so, for whoever comes here googling the same things as I did:

Config file that eventually worked for me:

conn Tunnel1
	authby=secret
	auto=start
	left=%defaultroute
	leftid=18.203.156.93
	right=52.208.223.115
	type=tunnel
	ikelifetime=8h
	keylife=1h
    phase2alg=aes_gcm_c;modp2048
    # The one below doesn't work. 'let systems figure it out' seems to work though
    # ike=aes_gcm_c;modp2048
	keyingtries=%forever
	keyexchange=ike
	leftsubnet=172.31.0.0/16
	rightsubnet=10.0.0.0/16
	dpddelay=10
	dpdtimeout=30
	dpdaction=restart_by_peer
    encapsulation=yes

Changes to config downloaded from AWS:

• Removal of auth=esp (as probably mentioned by course, it is in the one I follow: DigitalCloudTraining on Udemy)
• Change of phase2alg (based on what I saw in various logs on startup as being available. Trial and error)
• Disabling ike explicit config
• Adding of encapsulation=yes, baed on https://libreswan.org/wiki/Interoperability#ESP_packet_filter

End of journalctl looks like this:

# journalctl -xe  -u ipsec
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: loading secrets from "/etc/ipsec.secrets"
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: loading secrets from "/etc/ipsec.d/aws.secrets"
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #1: initiating Main Mode
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #1: STATE_MAIN_I2: sent MI2, expecting MR2
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #1: Peer ID is ID_IPV4_ADDR: '52.208.223.115'
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_128 integ=sha group=MODP2048}
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:035ab2c9 proposal=AES_GCM_16-NON
Jul 24 05:58:21 ip-172-31-29-113.eu-west-1.compute.internal pluto[17097]: "Tunnel1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0xc8cbd1a8 <0xf484c1ec xfrm=AES_GCM_16_128-NONE NATOA=none NATD=52.208.223.115:4500 DPD=act

Ipsec status can be helpful as well (initially active stuck at 0):

# ipsec status

000
000 Total IPsec connections: loaded 1, active 1
000
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(1), authenticated(1), anonymous(0)
000
000 #1: "Tunnel1":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 26106s; newest ISAKMP; lastdpd=0s(seq in:23780 out:0); idle; import:admin initiate
000 #2: "Tunnel1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 1147s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "Tunnel1" [email protected] [email protected] [email protected] [email protected] ref=0 refhim=0 Traffic: ESPin=252B ESPout=756B! ESPmax=4194303B
000
000 Bare Shunt list:
000

(🤷‍♂️ Feels like I've been beating an old car's engine with a hammer for hours and suddenly it runs. No clue if it will last...)