DEV Community: Jose Truyol

VPN Site-to-Site between Azure and Google Cloud Platform. Part 3

Jose Truyol — Mon, 25 Oct 2021 17:10:33 +0000

You can find this story, with more information, on my website https://blog.truyol.dev/vpn-site-to-site-between-gcp-and-azure-part-3/

If you had been following along, in the first part, we create a Site-to-Site VPN between Azure and GCP. In the second part we tested that connection successfully. Now it's time to secure it

Current scenario

At this point, we added 2 more VMs. Now we have 2 VMs on Azure and 2 VMs on GCP:

VM	Cloud Provider	Private IP
GCP-01	Google Cloud	`10.125.0.2`
GCP-02	Google Cloud	`10.125.0.3`
Azure-01	Azure	`10.128.0.2`
Azure-02	Azure	`10.128.0.3`

The goal

Protect the network on Azure, allowing only specific IPs to be reached, in a maintainable way. This means that later on, we can change which IPs are whitelisted without the need to re-deploy a new VPN.

On the first test we will prevent any incoming traffic to the Azure VNet keeping the outgoing traffic to the GCP network:

From	To	Can connect?
`GCP-01`	`Azure-01`	No
`GCP-01`	`Azure-02`	No
`GCP-02`	`Azure-01`	No
`GCP-02`	`Azure-02`	No
`Azure-01`	`GCP-01`	Yes
`Azure-01`	`GCP-02`	Yes
`Azure-02`	`GCP-01`	Yes
`Azure-02`	`GCP-02`	Yes

And, in the second test we will allow incoming traffic to only the Azure-01 VM:

From	To	Can connect?
`GCP-01`	`Azure-01`	Yes
`GCP-01`	`Azure-02`	No
`GCP-02`	`Azure-01`	Yes
`GCP-02`	`Azure-02`	No
`Azure-01`	`GCP-01`	Yes
`Azure-01`	`GCP-02`	Yes
`Azure-02`	`GCP-01`	Yes
`Azure-02`	`GCP-02`	Yes

How can we secure our Azure VPN?

Our Virtual Network Gateway was associated with a VNet (default-vnet with one subnet), and there is where we can protect our resources. We will use the Network Security Group (NSG) with some custom rules. But first, let's create the NSG

If we go to the resource overview page we can take a look into the inbound and outbound security rules

Now, we go to the VNet we want to secure and in the subnet, we apply the vpn-test-ng Network Security Group

We are now ready to start to implement our rules!

First test

In the Network Security Group, we go to the Inbound security rules on the sidebar and click on the Add button. Let's see what we need:

Field	Description	Value
Source	Specify the incoming traffic from a specific type of source	IP Addresses
Source IP addresses / CIDR ranges	CIDR of the source network	`10.125.0.0/20`
Source port ranges	From which ports this rule will take effect	`*`
Destination	Specify the outgoing traffic of this rule	Any
Service	Specify the destination protocol and port range for this rule	Custom
Destination port ranges	Ports of the destination targets	`*`
Protocol	To which protocol this rule will take effect	Any
Action	Define if this rule will allow or deny the traffic if the conditions are met	Deny
Priority	Sets the priority of this rule. Azure will evaluate from the lowest highest priority until it found a match rule	4000

We will use a high priority value because this is our fallback rule, denying everything. Later on, we can add specific rules to allow more narrowed traffic.

Our network should be secure from incoming traffic through the VPN. Let's check if we still have access to the GCP network:

azureuser@Azure-01$ ping 10.125.0.2 -c 4
PING 10.125.0.2 (10.125.0.2) 56(84) bytes of data.
64 bytes from 10.125.0.2: icmp_seq=1 ttl=64 time=50.644 ms
64 bytes from 10.125.0.2: icmp_seq=2 ttl=64 time=48.559 ms
64 bytes from 10.125.0.2: icmp_seq=3 ttl=64 time=53.577 ms
64 bytes from 10.125.0.2: icmp_seq=4 ttl=64 time=49.720 ms

--- 10.125.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3076ms
rtt min/avg/max/mdev = 48.559/50.625/53.577/2.063 ms

Awesome, everything keeps working! Let's try from GCP now:

ubuntu@GCP-01$ ping 10.128.0.2 -c 4
PING 10.128.0.2 (10.128.0.2) 56(84) bytes of data.
^C
--- 10.128.0.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms
ubuntu@GCP-01$ ping 10.128.0.3 -c 4
PING 10.128.0.3 (10.128.0.3) 56(84) bytes of data.
^C
-------- 10.128.0.3 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3053ms

ubuntu@GCP-02$ ping 10.128.0.2 -c 4
PING 10.128.0.2 (10.128.0.2) 56(84) bytes of data.
^C
-------- 10.128.0.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3053ms
ubuntu@GCP-02$ ping 10.128.0.3 -c 4
PING 10.128.0.3 (10.128.0.3) 56(84) bytes of data.
^C
-------- 10.128.0.3 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Excellent, our network is secure from any connection from the GCP network.

Second test

It's time to open only the Azure-01 VM to the GCP network. This can be done by creating a new Incoming security rule:

In this rule, we will use the IP Adresses destination with Azure-01 VM as the destination IP Address and the Allow action. Let's apply and try it out!

ubuntu@GCP-01$ ping 10.128.0.2 -c 4
PING 10.125.0.2 (10.125.0.2) 56(84) bytes of data.
64 bytes from 10.125.0.2: icmp_seq=1 ttl=64 time=50.644 ms
64 bytes from 10.125.0.2: icmp_seq=2 ttl=64 time=48.559 ms
64 bytes from 10.125.0.2: icmp_seq=3 ttl=64 time=53.577 ms
64 bytes from 10.125.0.2: icmp_seq=4 ttl=64 time=49.720 ms

-------- 10.125.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3076ms
rtt min/avg/max/mdev = 48.559/50.625/53.577/2.063 ms
ubuntu@GCP-01$ ping 10.128.0.3 -c 4
PING 10.128.0.3 (10.128.0.3) 56(84) bytes of data.
^C
-------- 10.128.0.3 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3053ms

ubuntu@GCP-02$ ping 10.128.0.2 -c 4-
PING 10.125.0.2 (10.125.0.2) 56(84) bytes of data.
64 bytes from 10.125.0.2: icmp_seq=1 ttl=64 time=50.644 ms
64 bytes from 10.125.0.2: icmp_seq=2 ttl=64 time=48.559 ms
64 bytes from 10.125.0.2: icmp_seq=3 ttl=64 time=53.577 ms
64 bytes from 10.125.0.2: icmp_seq=4 ttl=64 time=49.720 ms

-------- 10.125.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3076ms
rtt min/avg/max/mdev = 48.559/50.625/53.577/2.063 ms
ubuntu@GCP-02$ ping 10.128.0.3 -c 4
PING 10.128.0.3 (10.128.0.3) 56(84) bytes of data.
^C
-------- 10.128.0.3 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Awesome! We can now limit which IP addresses can be reached from the other side of the VPN, thus securing our network.

If you have a VPN device and wish to connect to the Azure VPN, you can refer to the official documentation and check the default values used in this VPN implementation.

Hope you found this series useful.

VPN Site-to-Site between Azure and Google Cloud Platform. Part 2

Jose Truyol — Thu, 21 Oct 2021 16:29:36 +0000

You can find this story, with more information, on my website https://blog.truyol.dev/vpn-site-to-site-between-gcp-and-azure-part-2/

If you had been following along, in the first part, we create a Site-to-Site VPN between Azure and GCP. Now it's time to test it

The goal

Our goal today will be:

Create a Virtual Machine on each cloud provider, inside the VNet used on the VPN configuration. For GCP will be the subnet 10.125.0.0/20 and for Azure will be within the address space 10.128.0.0/9
Check if the VM can see each other using the ping command using their private IPs

Creating the Virtual Machines

We will create simple and cheap VMs with Linux as the Operating System. So, we will use only bash when we reach the test part.

GCP

Azure

Accessing the Virtual Machines

Now, let's open 2 new terminal windows and connect to each machine using SSH:

GCP: gcloud beta compute ssh --zone "us-east1-b" "vpn-test-vm" --project "vpn-test-419573"
Azure: ssh -i .ssh/azure_vm_key.pem azureuser@39.125.46.15

Next, we will find each machine IP address:

GCP:

jose@vpn-test-vm:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
    link/ether 42:01:0a:7d:00:02 brd ff:ff:ff:ff:ff:ff
    inet 10.125.0.2/32 brd 10.125.0.2 scope global dynamic ens4
       valid_lft 76728sec preferred_lft 76728sec
    inet6 fe80::4001:aff:fe7d:2/64 scope link
       valid_lft forever preferred_lft forever

Azure:

ubuntu@Gitlab:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:3a:02:16:98 brd ff:ff:ff:ff:ff:ff
    inet 10.128.0.4/24 brd 10.128.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe02:1698/64 scope link
       valid_lft forever preferred_lft forever

Awesome, we have the private IP of the GCP VM (10.125.0.2) and the Azure VM (10.128.0.4)

Testing the VPN

Using the private IPs we will ping each other using the ping command. Let's find out if the VPN is up and running.

GCP:

jose@vpn-test-vm:~$ ping 10.128.0.4 -c 4
PING 10.128.0.4 (10.128.0.4) 56(84) bytes of data.
64 bytes from 10.128.0.4: icmp_seq=1 ttl=63 time=40.3 ms
64 bytes from 10.128.0.4: icmp_seq=2 ttl=63 time=41.6 ms
64 bytes from 10.128.0.4: icmp_seq=3 ttl=63 time=42.1 ms
64 bytes from 10.128.0.4: icmp_seq=4 ttl=63 time=42.0 ms

--- 10.128.0.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 40.268/41.482/42.059/0.734 ms

Azure:

ubuntu@Gitlab:~$ ping 10.125.0.2 -c 4
PING 10.125.0.2 (10.125.0.2) 56(84) bytes of data.
64 bytes from 10.125.0.2: icmp_seq=1 ttl=63 time=44.1 ms
64 bytes from 10.125.0.2: icmp_seq=2 ttl=63 time=43.2 ms
64 bytes from 10.125.0.2: icmp_seq=3 ttl=63 time=41.9 ms
64 bytes from 10.125.0.2: icmp_seq=4 ttl=63 time=41.7 ms

--- 10.125.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 41.702/42.745/44.118/1.007 ms

Excellent! We had proven that our VPN works on both ends. But, with the current approach, we left everything open on both sides. What if we want to restrict access to only 1 target machine in the network? We can do this by providing a more narrowed address space when creating the VPN but this is a security hole.

In the next part, we will be looking for a better solution.

VPN Site-to-Site between Azure and Google Cloud Platform. Part 1

Jose Truyol — Tue, 19 Oct 2021 21:18:34 +0000

You can find this story, with more information, on my website https://blog.truyol.dev/vpn-site-to-site-between-gcp-and-azure/

I never had the chance to deploy a VPN Server or configure a Site-to-Site connection. So this was a huge "must" on my professional bucket list.

Luckily I was tasked to perform some tests between Azure and GCP using IPsec IKEv2, and set the ground on how the company will create and protect this kind of connection. The task list was:

Choose the service with the best cost/feature ratio.
Create the resources on both ends and establish a connection.
Test the network
Limit the connection to specific IP/resources
Validate that we can deploy multiple VPN connections with different customers.

Without further ado, let's get into it.

Choosing the service

These secure connections will be needed only for the development and stage of our products. This way we can extract data securely from our client's data sources. That's why we don't need High Availability services on either end.

Azure

Azure offers 3 types of connections:

VNet-to-VNet: Simple way to connect VNets in azure. Similar to a Site-to-Site IPsec connection to an on-premises location.
Site-to-Site (IPsec): Composed by a VPN Gateway, a Local Gateway and a Connection, allows to send encrypted traffic between an Azure's VNet and an on-premises location through the public internet.
ExpressRoute: Lets us create private connections between Azure datacenters and on-premises infrastructure through the Microsoft private network. Also, have higher bandwidth over a Site-to-Site connection (up to 10Gbps vs <100Mbps)

We will use the Site-to-Site VPN this time.

Google Cloud Platform

GCP offers 3 types of connections:

Cloud VPN: This service has 2 subtypes:
- HA VPN: This is a High Availability Cloud VPN that lets us securely connect on-premises networks to our private networks on GCP through an IPsec VPN connection.
- Classic VPN: In contrast to HA VPN, Classic VPN have a single interface and a single external IP address.
Cloud Interconnect: Provides low latency and high availability connections to reliably transfer data between on-premises and GCP through a supported service provider or Google's network with no public internet dependency.
Cloud Router: Fully distributed and managed GCP Service that uses Border Gateway Protocol (BGP). Support custom dynamic routes based on the BGP advertisements that it receives from a peer.

In this opportunity, we will use Classic VPN

Create the resources

Requirements:

Azure:
- VNet with address space 10.128.0.0/9. In this case, it will be on useast-2
GCP:
- VNet with a subnet with address space 10.125.0.0/20. In this case it will be default VPC with the vpn-subnet on us-east1

It could be any address space, the most important is that they don't overlap.

Azure

Let's create a Virtual Network Gateway on Azure. This resource will be the public face of our VNet

Field	Description	Value
Name	Name of the Virtual Network Gateway	`vpn-test`
Region	The same as our VNet	`East US 2`
Gateway Type	Type of connection to use	`VPN`
VPN Type	Type of VPN to use. Route based will allow us to define the address space of this VPN	`VPN`
SKU	Tier of service to use. `VpnGwX` allows us to use IPsec	`VpnGw1`
Virtual Network	The VNet to associate to this VPN	`test-vnet`

When everything is created, we can see the public IP 20.97.253.157 on the Overview page of the resource.

Now, let's jump to GCP

GCP

Now that we have the public IP and the address space on the Azure side, we will create the Classic Cloud VPN resource

Cloud VPN

Field	Description	Value
Name	Name of the Cloud VPN resource	`vpn-test`
Network	GCP Network to link with this VPN	`default`
Region	GCP Region where our subnet is located	`us-east1`
IP address	New IP address request for this VPN	`vpn-test-ip`

Tunnel

Field	Description	Value
Name	Name of the VPN Tunnel	vpn-test-tunnel-1
Remote peer IP Address	Azure's VPN Gateway public IP	20.97.253.157
IKE version	Versión de IKE a usar	IKEv2
IKE pre-shared key	Key to encrypt the traffic	secret
Routing options	For simplicity we will use Route-Based routing	Route-Based
Remote network IP ranges	Correspond to the address space on Azure	10.128.0.0/9

After this resource is created we will copy and save the public IP address 34.138.192.84

Let's jump back to Azure to finish the VPN configuration

Azure

Now that we have the Virtual Network Gateway, we will create a Local Network Gateway with the GPC information.

Field	Description	Value
IP address	Public IP of the GCP gateway	`34.138.192.84`
Address space	Address space on GCP to connect with	`10.125.0.0/20`

We are almost there! Now we need to create the Connection using the Virtual Network Gateway and the Local Network Gateway previously created.

Field	Description	Value
Connection Type	VPN Connection type	`Site-to-Site IPsec`
Virtual network gateway	Virtual network previously created. The image is out-of-date	`vpn-test`
Local network gateway	Local Network Gateway previously created	`vpn-test-lng`
Shared key (PSK)	Secret key used in the GCP VPN	`secret`
IKE Protocol	The same as the GCP VPN	`IKEv2`

Verification

Finally, we have our VPN Site-to-Site completely created. We can verify this by checking the connection status on each side. In Azure, it should show Status: Connected on the Connection resource. In GCP it should show Status: Tunnel is up and running with a green check on the VPN Tunnel.

In the next part, we will verify that any virtual machine can reach the other side of the VPN using the private IPs.