Arseny Zinchenko

Posted on Mar 3, 2019 • Originally published at rtfm.co.ua on Feb 21, 2019

OpenVPN: OpenVPN Access Server set up and AWS VPC peering configuration

#aws #amazonwebservices #networking #openvpn

The OpenVPN Access Server is ready to use OpenVPN server which requires minimal configuration.

The free version allows you to have two clients. If you need more – you can buy additional licenses.

Infrastructure description

Currently to access our resources such as Jenkins, Nexus etc we are using Allow Rules in AWS Security Groups where each user has its own IP added.

This was not too bad approach while was a small team but as we are growing fast and there are more and more developers/QA – had to find a better solution.

In this post, we will set up an OpenVPN service using OpenVPN Access Server AWS AMI.

After all, everything will look like:

You can find documentation OpenVPN AS documentation here>>> and some VPC peering example will be shown in this post.

AWS: creating OpenVPN AS service

Running EC2

Find the AMI:

You can add license later so, for now, let’s use its Free version.

Take a t2.micro instance – it will be fair enough at this moment:

VPC

Create a new VPC for our VPN:

As we will use VPC peerings – make sure your networks aren’t overlapped.

In this case – I have Jenkins VPC with the 10.0.4.0/24 CIDR and VPC VPN CIDR – 10.0.9.0/24:

Create a new subnet in this VPC:

Configure new EC2 networking using those VPC and subnet:

Internet Gateway

Create Internet Gateway (IGW) to access the Internet from your new VPC:

Attach this IGW to your VPC:

Route table

Next, have to update a Route Table to be used to route traffic to the 0.0.0.0/0 network (the Internet) via created IGW.

Go to your new subnet, find the Route Table tab, click on it:

Add a new route via IGW:

Security Group

AWS will suggest you use a Security Group with an already predefined set of rules.

As this is such a Proof of Concept – you can leave it as is:

TCP 22 — SSH access
TCP 943 — OpenVPN AS admin UI access port
TCP 443 — OpenVPN AS users UI access port
UDP 1194 — OpenVPN UDP for VPN clients

In kind of Production setup, you have to limit 943 and 22 by only trusted IPs.

Start the instance, create new RSA key for access:

Elastic IP

Create an EIP to use it with your new host:

Attach it:

Source/Destination check disabling

For NAT’s correct work need to disable the Source/Dest check (see post AWS: миграция RTFM 2.5 — настройка NAT на Bastion EC2 как замена NAT Gateway и AWS: миграция RTFM 2.7 — CloudFormation и Ansible — наcтройка NAT):

And we are done with the EC2 now – let’s start configuring our new OpenVPN service.

OpenVPN AS set up

SSH to the host using the openvpnas login:

$ ssh -i dev-vpn-eu-west-1.pem openvpnas@52.18.110.226

Read :-) the license, accept it:

Initialization and the first configuration

On the first login, OpenVPN AS will start its wizard automatically.

You can run it later using the ovpn-init:

$ sudo ovpn-init --ec2

For now, you can just answer Yes with default values for everything here:

Will this be the primary Access Server node? // yes
Please specify the network interface and IP address to be used by the Admin Web UI: (1) all interfaces: 0.0.0.0 (2) eth0: 10.0.9.8 // 2
Please specify the port number for the Admin Web UI. // yes – 943
Please specify the TCP port number for the OpenVPN Daemon // yes – 443
Should client traffic be routed by default through the VPN? // no – we will route only traffic to our own resources
Should client DNS traffic be routed by default through the VPN? // no
Use local authentication via internal DB? // yes
Private subnets detected: [‘10.0.9.0/24’] Should private subnets be accessible to clients by default? // yes
Do you wish to login to the Admin UI as “openvpn”? // yes
> Please specify your OpenVPN-AS license key (or leave blank to specify later): // leave blank

Set the openvpn user ‘s password:

$ openvpnas@openvpnas2:~$ sudo passwd openvpn
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Now you can open your admin page using EIP created before – https://52.18.110.226:943/admin in this case.

As we didn’t configure a hostnames/URLs – just agree here:

Your connection is not private

Attackers might be trying to steal your information from 52.18.110.226 (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_AUTHORITY_INVALID

(check the OpenVPN: SSL and hostname configuration post - it was added later)

VPN client connection

Go to the user’s UI (no /admin at the end) – https://52.18.110.226:943/?src=connect:

Click on the Yourself (user-locked profile) and download the client.ovpn file with settings for your local VPN client:

$ cat ~/.openvpn/client.ovpn
Automatically generated OpenVPN client config file
Generated on Wed Feb 20 15:19:38 2019 by openvpnas2
Default Cipher
cipher AES-256-CBC
Note: this config file contains inline private keys
and therefore should be kept confidential!
Note: this configuration is user-locked to the username below
OVPN\_ACCESS\_SERVER\_USERNAME=openvpn
...

Install the openvpn package on your local PC, here is Arch Linux used:

$ sudo pacman -S openvpn

Start it with the --auth-user-pass option:

$ sudo openvpn --config ~/.openvpn/client.ovpn --auth-user-pass
Wed Feb 20 17:22:42 2019 OpenVPN 2.4.6 x86\_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Wed Feb 20 17:22:42 2019 library versions: OpenSSL 1.1.1a  20 Nov 2018, LZO 2.10
Enter Auth Username: openvpn
Enter Auth Password: \*\*\*\*\*\*\*
...
Wed Feb 20 17:22:51 2019 ROUTE\_GATEWAY 172.16.64.1/255.255.252.0 IFACE=wlp2s0 HWADDR=10:f0:05:64:0a:73
Wed Feb 20 17:22:51 2019 TUN/TAP device tun0 opened
Wed Feb 20 17:22:51 2019 TUN/TAP TX queue length set to 100
Wed Feb 20 17:22:51 2019 do\_ifconfig, tt-\>did\_ifconfig\_ipv6\_setup=0
Wed Feb 20 17:22:51 2019 /usr/bin/ip link set dev tun0 up mtu 1500
Wed Feb 20 17:22:51 2019 /usr/bin/ip addr add dev tun0 172.27.232.3/21 broadcast 172.27.239.255
Wed Feb 20 17:22:56 2019 ROUTE remote\_host is NOT LOCAL
Wed Feb 20 17:22:56 2019 /usr/bin/ip route add 52.18.110.226/32 via 172.16.64.1
Wed Feb 20 17:22:56 2019 /usr/bin/ip route add 10.0.9.0/24 metric 101 via 172.27.232.1
Wed Feb 20 17:22:56 2019 /usr/bin/ip route add 172.27.224.0/20 metric 101 via 172.27.232.1
Wed Feb 20 17:22:56 2019 Initialization Sequence Completed

Now – let’s check some routing.

First, let’s make a request to the CloudFlare – it must be passed via my office’s router/gateway:

$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1  \_gateway (172.16.64.1)  3.109 ms  3.213 ms  3.428 ms
2  ru-german.relc.com (194.183.169.25)  4.771 ms  5.148 ms  6.039 ms
3  \* \* \*
4  ex4.thinx.pl (212.91.2.13)  16.468 ms  16.778 ms  17.277 ms
5  cloudflare.thinx.pl (212.91.0.28)  23.842 ms  24.154 ms  24.386 ms
6  one.one.one.one (1.1.1.1)  17.787 ms  15.023 ms  15.199 ms

Yup, it is.

And now to the OpenVPN host – must go directly:

$ traceroute 10.0.9.8
traceroute to 10.0.9.8 (10.0.9.8), 30 hops max, 60 byte packets
1  10.0.9.8 (10.0.9.8)  52.095 ms  52.149 ms  53.512 ms

Nice.

VPN-tunnel traffic routing

For the testing purposes – let’s add a new EC2 in the same VPC where is our OpenVPN placed:

And let’s check routes again.

During local OpenVPN client start you have to notice a message with new routes to be added in your system:

Wed Feb 20 17:22:56 2019 /usr/bin/ip route add 172.27.224.0/20 metric 101 via 172.27.232.1

Check it – try SSH using Private IP of the new instance:

$ ssh -i dev-vpn-eu-west-1.pem ubuntu@10.0.9.6
The authenticity of host '10.0.9.6 (10.0.9.6)' can't be established.
ECDSA key fingerprint is SHA256:6ldjTtHvQJviBb/9aXwFvwh7nwKjOdpePCxO6TddAJA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.9.6' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-1021-aws x86\_64)
...
ubuntu@ip-10-0-9-6:~$

All good.

VPC peering

The next step is to configure VPC-peering and a traffic routing between our workstation, VPN-server, and the Jenkin’s VPC.

VPC-peering routing

If you’ll try to connect to the Jenkins using its Private IP – this will not work now:

ubuntu@ip-10-0-9-6:~$ ssh admin@10.0.4.13
ssh: connect to host 10.0.4.13 port 22: Connection timed out

Because there are no routes added between the 10.0.9.0/24 (OpenVPN VPC) and the 10.0.4.0/24 (Jenkins VPC) networks.

So now we have to add two new routes:

in the Jenkins route table – 10.0.4.0/28 => 10.0.9.0/24 via VPC peering created above
in the OpenVPN route table – 10.0.4.0/28 => 10.0.9.0/24 via VPC peering created above

Edit the jenkins rtb-9597e6ec | jenkins-dev-route-table table:

Add the new route:

Repeat for the VPN’s route table:

Check from the VPN network:

ubuntu@ip-10-0-9-6:~$ ping 10.0.4.13
PING 10.0.4.13 (10.0.4.13) 56(84) bytes of data.
64 bytes from 10.0.4.13: icmp\_seq=1 ttl=64 time=0.470 ms
64 bytes from 10.0.4.13: icmp\_seq=2 ttl=64 time=0.483 ms

And from the Jenkins host – back to the VPN’s network to any host:

admin@jenkins-dev:~$ ping 10.0.9.6
PING 10.0.9.6 (10.0.9.6) 56(84) bytes of data.
64 bytes from 10.0.9.6: icmp\_seq=1 ttl=64 time=0.437 ms
64 bytes from 10.0.9.6: icmp\_seq=2 ttl=64 time=0.914 ms

Remember that Jenkins has its own Security Group – add new Allow rule there.

Check SSH from the VPN’s network:

ubuntu@ip-10-0-9-6:~$ ssh admin@10.0.4.13
The authenticity of host '10.0.4.13 (10.0.4.13)' can't be established.
ECDSA key fingerprint is SHA256:+0LP1+neT4udq96jFLdLpjuvTrWCzlAt5GZZpfw2rKI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.4.13' (ECDSA) to the list of known hosts.
admin@10.0.4.13: Permission denied (publickey).

And back:

admin@jenkins-dev:~$ ssh 10.0.9.6
The authenticity of host '10.0.9.6 (10.0.9.6)' can't be established.
ECDSA key fingerprint is SHA256:6ldjTtHvQJviBb/9aXwFvwh7nwKjOdpePCxO6TddAJA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.9.6' (ECDSA) to the list of known hosts.
Permission denied (publickey).

Good.

VPN routes

Go back to your workstation and check how traffic will be routed to the Jenkins host, using its Private IP:

$ traceroute 10.0.4.13
traceroute to 10.0.4.13 (10.0.4.13), 30 hops max, 60 byte packets
1  \_gateway (172.16.64.1)  3.243 ms  3.453 ms  3.656 ms
2  ru-german.relc.com (194.183.169.25)  3.962 ms  4.221 ms  4.642 ms
...

It is passed through the office’s router – and this is absolutely not what we want.

Go to the VPN admin => VPN Settings – https://52.18.110.226:943/admin/vpn\_settings:

Add a new NAT-rule for the 10.0.4.0/24 subnet:

Save, press Update Running Server:

Restart local client:

$ sudo openvpn --config ~/.openvpn/client.ovpn --auth-user-pass
...
Wed Feb 20 18:25:37 2019 ROUTE remote\_host is NOT LOCAL
Wed Feb 20 18:25:37 2019 /usr/bin/ip route add 52.18.110.226/32 via 172.16.64.1
Wed Feb 20 18:25:37 2019 /usr/bin/ip route add 10.0.4.0/24 metric 101 via 172.27.232.1
Wed Feb 20 18:25:37 2019 /usr/bin/ip route add 10.0.9.0/24 metric 101 via 172.27.232.1
Wed Feb 20 18:25:37 2019 /usr/bin/ip route add 172.27.224.0/20 metric 101 via 172.27.232.1
Wed Feb 20 18:25:37 2019 Initialization Sequence Completed

Here is our new route – 10.0.4.0/24 metric 101 via 172.27.232.1.

Check your local routing table:

18:26:28 [setevoy@setevoy-arch-work ~]  $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.64.1     0.0.0.0         UG    303    0        0 wlp2s0
10.0.4.0        172.27.232.1    255.255.255.0   UG    101    0        0 tun0
10.0.9.0        172.27.232.1    255.255.255.0   UG    101    0        0 tun0
52.18.110.226   172.16.64.1     255.255.255.255 UGH   0      0        0 wlp2s0

Check trace again:

$ traceroute 10.0.4.13
traceroute to 10.0.4.13 (10.0.4.13), 30 hops max, 60 byte packets
1  172.27.232.1 (172.27.232.1)  55.090 ms  55.207 ms  55.399 ms
...

Now it went via OpenVPN IP as a gateway.

Check if SSH works via Private IP:

18:27:41 [setevoy@setevoy-arch-work ~]  $ ssh -i jenkins-dev-eu-west-1.pem admin@10.0.4.13
...
admin@jenkins-dev:~$

“It works!” (c) :-)

DNS

The last thing to think about is the DNS settings.

As our Jenkins has to be accessible using its Public IP and domain dev.ci.example.com from a few addresses on the Internet and via its Private IP – using VPN connection – need to find a way resolve it to a different IPs.

Check the OpenVPN: DNS and dnsmasq configuration post for details.

Done.

Top comments (2)

udongeex • Mar 31 '20

Hello, is there a way to open internet access when connected to vpn

Arseny Zinchenko • Mar 31 '20

Hi, sure.
In our setup, all traffic to the Internet will be sent as usual, via a user provider, and only requests to our private networks will be served via the VPN connection.

DEV Community