Today time is precious, and this means that decisions are made rapidly and one hour can be the border between disaster and success. In such times the companies are adapting and this means that individuals are accessing business applications everywhere: at the office, during the daily commute, or at home.
With this mobility, new risks of cyber-attacks arise and in order to mitigate them, companies are implementing security controls that are enforcing data encryption.
Now with the digital revolution, a lot of applications that are web-based are moving to the cloud, so to keep the security controls in place two methods are widely spread:
Encryption at the application layer using TLS;
Encryption at the network layer using virtual private networks (VPN).
Looking at Moore’s law we see an increase in the computational power of the personal computer's CPUs and this means that attacks on the TLS are easy to do by a normal user of the Internet. This leads enterprises to employ besides application encryption also network encryption.
All the cloud providers are supporting out of the box Site-to-Site VPN in which offices have a secured connection to the cloud, but what they are lacking is Remote Access VPN support. This can be resolved with the use of network appliances from Palo Alto, Fortinet, Cisco, and Checkpoint, which implies licensing costs that are a burden for small companies.
In this article, we will focus on installing a Remote Access VPN into OCI. For this, we will use a Linux OEL7 with Libreswan. This is meant only to be a proof of concept and it is a basic solution (PSK vpn and PPP authentication for the users).
For the OCI infrastructure, I will use a simple setup - one VCN with two subnets: one public and the second is private. The network topology can be found below:
Creating the cloud artifacts is not in the scope of this article, so the VCN with the subnets, the VMs, and the additional vNIC are prerequisites.
First, we create a Linux VM in the public subnet and we will attach a secondary vNIC from the private subnet.
Install libreswan:
Install l2tp support:
By default the Linux OS is not allowing forwarding the packet between it's vNICs, so we need to activate routing.
echo 1 > /proc/sys/net/ipv4/ip_forward |
Configure the Libreswan as a Remote access VPN:
/etc/ipsec.d/ra.conf conn ikev1 authby=secret pfs=no auto=add left=%defaultroute right=%any type=transport leftprotoport=17/1701 rightprotoport=17/%any |
The security of this PoC relays on the pre-shared (PSK) key used. We will try to make this password hard to break via brute force techniques by randomly generating a random alphanumerical combination with the length of 32 characters:
PSK
</dev/urandom tr -dc _A-Z-a-z-0-9-'!@#$%^&*()_+-={}[]:;"<>,./?|' | head -c32; echo "" |
The output will look like this:
The PSK that we create will be use in the secrets file:
/etc/ipsec.d/ra.secrets : PSK "M#@F>^ZCpR-/+82oP+C46YX]SXgy7H?D" |
At this point the libreswan configuration is done and we will proceed in stating the ipsec service:
[root@caandrei-libreswan-01 ~]# systemctl start ipsec [root@caandrei-libreswan-01 ~]# systemctl status ipsec ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2019-09-04 13:25:51 GMT; 4s ago Docs: man:ipsec(8) man:pluto(8) man:ipsec.conf(5) Process: 10949 ExecStartPre=/usr/sbin/ipsec --checknflog (code=exited, status=0/SUCCESS) Process: 10942 ExecStartPre=/usr/sbin/ipsec --checknss (code=exited, status=0/SUCCESS) Process: 10423 ExecStartPre=/usr/libexec/ipsec/_stackmanager start (code=exited, status=0/SUCCESS) Process: 10421 ExecStartPre=/usr/libexec/ipsec/addconn --config /etc/ipsec.conf --checkconfig (code=exited, status=0/SUCCESS) Main PID: 10962 (pluto) Status: "Startup completed." CGroup: /system.slice/ipsec.service └─10962 /usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: adding interface ens3/ens3 10.10.10.2:500 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: adding interface ens3/ens3 10.10.10.2:4500 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: adding interface lo/lo 127.0.0.1:500 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: adding interface lo/lo 127.0.0.1:4500 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: | setup callback for interface lo:4500 fd 19 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: | setup callback for interface lo:500 fd 18 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: | setup callback for interface ens3:4500 fd 17 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: | setup callback for interface ens3:500 fd 16 Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: loading secrets from "/etc/ipsec.secrets" Sep 04 13:25:51 caandrei-libreswan-01 pluto[10962]: loading secrets from "/etc/ipsec.d/ra.secrets" |
After the overlay ipsec tunnel is created we will need the user authentication and the inner IP addresses. In Linux, this is done with L2tp and chap. Edit the l2tp.conf and modify the entries to reflect your setup:
/etc/xl2tpd/xl2tpd.conf listen-addr = 10.10.10.2 ip range = 192.168.11.24-192.168.11.26 local ip = 192.168.11.11 |
Create a random password and add it to the /etc/ppp/chap-secrets file:
</etc/ppp/chap-secrets catalin * "F=):5^5{by?nv9]qm>)g(?EK.?n(A+q>" 192.168.11.24 |
Start the l2tp service:
systemctl start xl2tpd |
When connecting to the server you can observe the IPSEC logs:
packet from 86.120.51.119:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001] responding to Main Mode from unknown peer 86.120.51.119 on port 500 STATE_MAIN_R1: sent MR1, expecting MI2 STATE_MAIN_R2: sent MR2, expecting MI3 Peer ID is ID_IPV4_ADDR: '192.168.0.167' STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=DH20} the peer proposed: 130.61.210.77/32:17/1701 -> 192.168.0.167/32:17/0 NAT-Traversal: received 2 NAT-OA. Using first, ignoring others responding to Quick Mode proposal {msgid:01000000} us: 192.168.12.8:17/1701 them: 86.120.51.119:17/1701 STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 transport mode {ESP/NAT=>0xa9814dcc <0xc4406fd2 xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=192.168.0.167 NATD=86.120.51.119:4500 DPD=passive} STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0xa9814dcc <0xc4406fd2 xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=192.168.0.167 NATD=86.120.51.119:4500 DPD=passive} |
The Ipsec tunnel is established and after that the ppp user authentication is done via the tunnel:
using channel 8 Using interface ppp0 Connect: ppp0 <--> /dev/pts/2 sent [LCP ConfReq id=0x1 |
Previous Post