How to setup VPN from on-premises to Google Cloud VPC - google-cloud-platform

We want to be able to connect to my on-premise database from our google cloud kubernetes.
We are currently attempting to do so by using "Create a VPN connection" from within the google console.
In the field IP address, I am forced to create (or pick from existing) "External IP Addresses".
I am able to link a single VM-instance to this External IP Address. But I want my VPN connection/tunnel to be between my on-premises network and EVERYTHING within my Google cloud network.
This IP should not just work as External IP Addr. for a single instance. I need to make it a gateway to the network as a whole. What am I missing?
Thanks in advance.
Another way to frame the question:
How do I find the IP Address of the gateway to my Google cloud network (VPC) and how do I supply that IP to the VPN Connection creation ?

The Cloud VPN connects your on-premises to the VPC, that means every Instance, Cluster or other products that use Google Cloud Engine (GCE).
As mentioned in a previous answer from avinoam-meir 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:
Tunnel using Dynamic Routing
Route Based VPN
Policy based VPN
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.

The answer was simpler than I thought.
My question was:
How do I find the IP Address of the gateway to my Google cloud network
(VPC) and how do I supply that IP to the VPN Connection creation ?
The answer is simply to fill out the "Create a VPN connection" page. It automatically sets up whatever IP you get/choose in the "IP Address" field as the gateway. I did NOT need to configure this IP address to work as a gateway. Simply getting it assigned in this step is enough. Google does the rest behind the scenes.

You need to distinguish between gateway IP address and local IP range of the VPN tunnel
The gateway IP address is the IP of the gateway where all the packets from your on-premises arrive encapsulated and encrypted.
The local IP range of the VPN tunnel is the range of IPs that can be reached through the VPN tunnel. By default this is all the
private IP addresses of your GCP network

Create a NAT gateway [1] with Kubernetes Engine and Compute Engine Network Routes to route outbound traffic from an existing GKE cluster through the NAT Gateway instance.
Use that NAT gateway IP address to create a VPN connection to remote peer gateway.
[1] https://cloud.google.com/solutions/using-a-nat-gateway-with-kubernetes-engine

Related

Cannot edit "Network endpoint group" and Network endpoints in the group after creating it in Google Cloud Platform

I just create a Network endpoint group based on the instructions in https://www.albinsblog.com/2020/06/how-to-enable-google-cdn-for-custom-origin-websites.html#.YPTQgab7SM8. However, after that, when I try to check the group, I can see its details, but there are no option to edit it, such as changing the default port. The only option is to "Delete" it.
The same thing happens in the network endpoints in this group. I can remove one network endpoints, but cannot edit its IP address or port.
Why?
After you create the internet NEG, the type cannot be changed between INTERNET_FQDN_PORT and INTERNET_IP_PORT. You need to create a new internet NEG and change your backend service to use the new internet NEG. Each endpoint is specified either by an IP address or an IP:port combination. you can only attach endpoints that belong to a VM's primary internal IP address in NEG's VPC network. Primary internal IP addresses from any NIC of a multi-NIC VM can be added to a NEG if the NEG uses the same VPC network as the NIC.
Every endpoint in the NEG must be a unique IP address and port combination. A unique endpoint IP address and port combination can be referenced by more than one NEG.
Each endpoint VM must have a network interface (NIC) in the same VPC network as the NEG. Endpoint IP addresses must be associated with the same subnet specified in the NEG.
I suggest you refer to Troubleshooting NEG issues, Setting up Cloud CDN with an external backend.

GCP Kubernetes block IP address?

What is the standard way to block an external IP from accessing my GCP cluster? Happy for the answer to include another Google service.
Because your cluster is deployed on Compute Engine instance, you can simply set a firewall rule to discard connection from a specific IP.
If you use an HTTP load balancer, you can add Cloud Armor policy to exclude some IPs.
In both case, keep in mind that IP filtering isn't very efficient. A VPN or Proxy can be easily and freely used on the internet and change the IP source of the requester.

Compute Engine in VPC can't connect to Internet & Cloud Storage after establishing Cloud VPN

Assuming I have a custom VPC with IP ranges 10.148.0.0/20
This custom VPC has firewall rules to allow-internal so the service inside those IP ranges can communicate to each other.
After the system grows I need to connect to some on-premises network by using Classic Cloud VPN, already create Cloud VPN (the on-premises side configuration already configured by someone) and the VPN Tunnel already established (with green checkmarks).
I also can ping to on-premises IP right now (let's say ping to 10.xxx.xxx.xxx where this is not GCP internal/private IP but on-premises private IP) using compute engine created on custom VPC network.
The problem is all the compute engine instance spawn in custom VPC network can't communicate to the internet now (like doing sudo apt update) or even communicate to google cloud storage (using gsutil), but they can communicate using private IP.
I also can't spawn dataproc cluster on that custom VPC (I guess because it can't connect to GCS, since dataproc needs GCS for staging buckets).
Since I do not really know about networking stuff and relatively new to GCP, how to be able to connect to the internet on instances that I created inside custom VPC?
After checking more in-depth about my custom VPC and Cloud VPN I realize there's misconfiguration when I establish the Cloud VPN, I've chosen route-based in routing option and input 0.0.0.0/0 in Remote network IP ranges. I guess this routes sending all traffic to VPN as #John Hanley said.
Solved it by using policy-based in routing option and only add specific IP in Remote network IP ranges.
Thank you #John Hanley and
#guillaume blaquiere for pointing this out

Check that VM on GCP is connecting to GCP VPN Gateway

How do I confirm that my VM connects to my GCP VPN Gateway? The two are already on the same network. I have tried pinging to the VPN Gateway IP from the vm but I cannot.
You would have to review and make sure that:
The VPN is active under Cloud VPN
Ensure that your GCP and on-prem firewall are allowing ingress/egress traffic between them
Depending on the type of VPN you choose, make sure that the IP address of the VM is shared to your on-prem via BPG, Route or Policy
If you see an issue with the VPN, you can review the VPN logs logs via logging (log viewer) and choose GCE Router. https://cloud.google.com/logging/docs/view/overview
If the issue is with the BGP/Route/Policy based, you would need to ensure your VPN IP is part of the shared range on both side (GCP and on-prem). https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview#classic-vpn
If the issue is with Firewall, make sure that nothing is blocking your VM from communicating with your VPN IP range on GCP side and on your on-prem side. https://cloud.google.com/network-connectivity/docs/vpn/how-to/configuring-firewall-rules
Here is more troubleshooting you can review/try: https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting

Consul and EC2 instance

I have set up a EC2 micro instance and installed Consul, but I can't seem to connect via Curl. I can connect to the instance from itself with curl http://localhost:8500/v1/agent/self for a test. However when I try to use the AWS public ipv4 from my local machine like so http://34.230.X.X:8500/v1/agent/self I get a connection refused. On the security group I have configured inbound port 8500 open to everyone. Everything seems to be in place and correctly configured is there something I'm missing?
The AWS VPC documentation has some steps for allowing EC2 instances to be reachable from the internet:
Attach an Internet gateway to your VPC.
Ensure that your subnet's route table points to the Internet gateway.
Ensure that instances in your subnet have a globally unique IP address (public IPv4 address, Elastic IP address, or IPv6 address).
Ensure that your network access control and security group rules allow the relevant traffic to flow to and from your instance.
It sounds like you have the public IPv4 address and have verified that the security groups are good; now just make sure you don't have any network ACLs set (or set appropriately if you have them), the internet gateway, and the route table.
It sounds like you need to set consul's client address to that of the public facing IP. You can do this with the -client option.
consul agent -server -bootstrap -bind="<Your private IP>" -client="<Your public IP>" -data-dir="<Your data dir>"
Disclaimer: This would allow anyone on the internet access to this consul agent's API. So take appropriate actions to secure this thing.