0

I have an instance (Linux-based) connected to a Google VPC Network that itself has a route to a peer VPN via IpSec Tunnel (IKev2).

The VPN Tunnel has Status Established in Google Cloud so everything seems to be up and running.

What do I have to configure in Linux to be able to access the other network? The netword card (eth0) is on the subnet that is configured for the VPC Network (that is tunneled to the peer VPN).

Thanks

Ohan
  • 1

3 Answers3

0

The Cloud VPN connects your on-premises to the VPC, which means that every instance, cluster or other products that use Google Cloud Engine (GCE).

The VPN has at least two components: Gateway and Tunnel but I will add a third one: Type of routing.

a) Gateway: This is where you can add an existing or reserve any static IP address (from the Google Pool of External IP Addresses).

b) Tunnel: Where the encapsulated and encrypted traffic will flow to reach the Local IP ranges.

c) Type of routing: Cloud VPN has three possibilities:

Depending on the type you choose, the routing happens in a different way but in general terms, it will propagate your subnetwork(s) to your on-premises network and receive the routes from it.

Important: Remember to open your firewall on your GCP VPC to receive traffic from your on-premises IP Ranges as the default and implied rule for Ingress will block it.

  • The implied allow egress rule: An egress rule whose action is allow, destination is 0.0.0.0/0, and priority is the lowest possible (65535) lets any instance send traffic to any destination.
  • The implied deny ingress rule: An ingress rule whose action is deny, source is 0.0.0.0/0, and priority is the lowest possible (65535) protects all instances by blocking incoming traffic to them.

Furthermore, if you have any other questions, please feel free to let me know.

Anthony Leo
  • 171
  • 4
  • Thanks! I have set up accordingly: Route based VPN to 0.0.0.0/0 on the VPN-tunnel. Looking at the stackdriver logs the connection is established and fine. The subnet which the VM is on is connected to NET1. NET1 has a route to the VPN tunnel. NET1 has firewall rules to allow all Ingress traffic. The VM still can't ping an IP on my peer VPN. What could be missing here? – Ohan Mar 27 '20 at 15:11
  • Could it be that on the VM instance configuration does not allow http/https traffic on the instance? – Anthony Leo Mar 27 '20 at 15:29
  • No both Allow HTTP traffic, Allow HTTPS traffic are Checked on the instance so it shouldn't be that. Does it matter if I set policy-based or route-based routing on the tunnel if I set destination to 0.0.0.0/0? – Ohan Mar 27 '20 at 15:48
  • One more question: Does the priority of the Routes matter. I have both Route to Internet and Route to VPN Tunnel. Which priority should VPN tunnel-route have? – Ohan Mar 27 '20 at 15:53
  • For the routing part, its expected to use the 0.0.0.0/0 as explained at https://cloud.google.com/vpn/docs/how-to/creating-static-vpns When you create a route based tunnel using the Cloud Console, Classic VPN performs both of the following tasks: Sets the tunnel's local and remote traffic selectors to any IP address (0.0.0.0/0) The route priorities do matter, please refer to https://cloud.google.com/vpn/docs/concepts/order-of-routes – Anthony Leo Mar 27 '20 at 18:09
  • Hi, Ok I've read all this but I don't quite follow still. On NET1, I have a Route to Default Internet Gateway and a route to the VPN tunnel. If they have the same priority, I cannot SSH the VM on NET1. How should the prio be set on these routes? – Ohan Mar 31 '20 at 15:04
0

I have a similar problem:

Route based vpn

In the vpc I have linux1, lunux2, and windows1. In my private LAN I have linuxP1

  1. I can ping ping between linux1 and linux2.
  2. From linux1 or linux2 I can not ping windows1 nor linuxP1
  3. From linuxP1 I can ping windows1 but I can not ping linux1 nor linux2
  4. From the Internet I have access to linux1, linux2, windows1

¿ Do I need additional configuration for linux1 and linux2 ?

szs
  • 1
0

I suspect there may be a small amount of confusion between what a route and a traffic selector are. A traffic selector, which you currently have configured as 0.0.0.0/0 on the GCP side of your VPN is considered an “encryption domain”. You can also think of it like a “hall pass” which defines which traffic sources are allowed to enter or use the VPN. However, “a traffic selector is not a route”.

Once you have defined the traffic selectors and your VPN is established, you still have to tell your VPC what traffic should use the VPN as a next-hop. Defining the traffic which will be sent to the VPN is done by creating a static route for your VPC, with a next-hop of the VPN. A policy-based or route-based Classic VPN tunnel uses static routing (you have created a route-based tunnel).

From the “route-based” link above:

“If you create one of these tunnels using the Cloud Console, Google Cloud 
automatically creates custom static routes based on the remote IP ranges you 
specify in the Cloud VPN configuration. If you use gcloud commands to create one 
of these tunnels, you must manually create the static routes that use the tunnel 
as a next hop.”

This means that depending on what traffic selector you used for the far-side of the VPN (not the “NET1” side), a static route may have been created for you. However, if you used something like 0.0.0.0/0 as a traffic selector on both sides of the VPN, then this static route will not do much. To have traffic be routable through the VPN, you will likely need to define a static route in NET1 which points to the subnet in your peer VPN that you wish to communicate with. This static route will need a next-hop of the NET1 VPN.

Please note: the same is true for the far side of the VPN. A static route (in the peer VPN VPC/network) which points to the subnet in NET1 that you wish to communicate with, will need to be created with a next-hop of the “peer VPN”.

As you have already opened the firewall on both sides of the VPN, once you create appropriate static routes, you should be able to ping from a subnet in NET1 to the peer VPN subnet (provided the static routes match).

TheRovinRogue
  • 128
  • 4