I have an AWS account with a VPC in Ireland and another in Sydney, which are connected via VPC peering.
I have 2 Windows servers, one in Ireland, one in Sydney, both are in a Private Subnet. From a server in Ireland I can RDP to the server in Sydney using it's private address, therefore my VPC peer is working.
To connect to the Ireland server, I have an OpenVPN server in the public subnet which I connect the OpenVPN client on my client machine. Once connected, I can RDP to the Ireland server. All good.
I am trying to connect to the Sydney server from my client machine, using the route client --> Ireland --> VPC link --> Sydney.
I have pushed routes via my OpenVPN config which means, when I ping the Sydney server, it now goes via the VPN instead of my home router but times out after the first hop.
C:\Windows\system32>tracert -d 10.150.224.50
Tracing route to 10.150.224.50 over a maximum of 30 hops
1 26 ms 25 ms 25 ms 10.41.0.1
2 * * * Request timed out.
I am at a loss of what happens after that hop, there is also a possibility that I have some config missing in OpenVPN. Any help / guidance would be greatly appreciated!
Unfortunately you cannot do what you want in AWS.
This is an invalid configuration, as per AWS docs:
Edge to edge routing through a gateway or private connection
If either VPC in a peering relationship has one of the following connections, you cannot extend the peering relationship to that connection:
A VPN connection or an AWS Direct Connect connection to a corporate network
An internet connection through an internet gateway
An internet connection in a private subnet through a NAT device
A gateway VPC endpoint to an AWS service; for example, an endpoint to Amazon S3.
For example, if VPC A and VPC B are peered, and VPC A has any of these connections, then instances in VPC B cannot use the connection to access resources on the other side of the connection. Similarly, resources on the other side of a connection cannot use the connection to access VPC B.
You have two options:
Configure your OpenVPN server to do NATing instead of routing and therefore "hide" the real source IP of the connection
Create another VPN connection with another OpenVPN server in Sydney region
Related
Within one project, I created two VPC networks, one in region us-central1 and one in region us-east1. Each has subnet 10.0.x.0/24. I know I could use VPC peering to connect these two subnets, however my goal is to verify I can setup a HA VPN connection between these two VPC networks.
Foreach VPC network I created an HA VPN gateway, named for their respective region: "vpn-gateway-central" and "vpn-gateway-east"; each has two public IP's for HA. I created two (one per each VPC) cloud routers for BGP use.
I fail when I try to create the VPN tunnels. My expectation based on available online tutorials (that have an older GCP UI) is that I create the tunnels in both directions, just like non-cloud VPN tunnels. From the central to the east, I attempt to create the tunnel in the "central" VPC, and I expect its remote peer(s) will be the set of IP's from the "east" VPC.
The GCP UI does something unexpected: It has me "SELECT PROJECT", and then it populates a drop-down for the "VPN gateway name" from which I select the peer. In this case, I would expect to see a list of VPN gateways that DO NOT exist within the VPC network from which I am starting. Thus, if I am starting from the "central" VPC network, then I expect to see the "east" VPC network in the "VPN gateway name". However, all I see is the VPN gateway name within the "central" region. The initiator and the peer IP's cannot be the same, but that is the result of making the only selection offered in the listbox "VPN gateway name".
I clearly cannot create this tunnel. Is this a bug in the new UI? Is this a beta? This GCP console UI has definitely changed from the ones I see in the online tutorials - where it appears to work (it exposes the remote VPN gateways, as one would intuitively expect, not the ones resident to the VPC network from which I am creating the tunnel).
This is my first VPN within GCP, so I'm likely missing something. However, in any case, if it's not broken, then at least it appears confusing. I will appreciate clarification/trick/workaround.
link to the GCP "Add VPN tunnels" dialogue where the unexpected list of VPN gateway names appears
I added another pic that shows the dialogue.
I didn't notice any issue regarding Cloud VPN from GCP.
To create a HA VPN between VPCs, this is the proper documentation.
In case you cannot create via UI, you can try to create it via gcloud commands, and you'll get more information about the issue that could be happening.
I recommend to check this, follow the guide and paste here the output of the gcloud commands if it fails.
So I have GCP set up and Kubernetes, I have a web app (Apache OFBiz) running on pods in the GKE cluster. We have a domain that points itself to the web app, so essentially it's accessible from anywhere on the internet. Our issue is since this is a school project, we want to limit the access to the web app to the internal network on GCP, we want to simulate a VPN connection. I have a VPN gateway set up, but I have no idea what to do on any random computer to simulate a connection to the internal network on GCP. Do I need something else to make this work? What are the steps on the host to connect to GCP? And finally, how do I go about limiting access to the webapp so only people in the internal network have access to the webapp?
When I want to test a VPN, I simply create a new VPC in my project and I connect both with Cloud VPN. Then, in the new VPC, you can create VM that simulate computer in the other side of the VPN and thus simulate what you want.
To setup a VPN on GCP you can use Cloud VPN using static or dynamic routing, you will need to configure a remote peer from the location you want to access your GCP resources to establish the connection towards the Cloud VPN gateway on GCP end.
This means you may require a router that supports creating VPN tunnels on your on-premises or use a host that acts like a router to establish this connection using a VPN software towards Cloud VPN (like Strongswan, for example).
You can block external access to the resources on your VPC network by using GCP firewall rules and just allow specific ports or source IP ranges as you wish.
Another option, even if it's not a VPN or encrypted traffic, is to only allow ingress traffic from the public IP from where you would like to connect to your internal VPC, but this is less secure and would only work if you have an static public IP on your on-premises.
Since you said this is a school project, I would recommend asking your teacher for more direct advice. That said, you can't "simulate" a VPN but you can set up an IPSec client on your laptop or whatever and actually connect to it. Unfortunately Google doesn't appear to have any documentation on this so I'm guessing they presume you already know IPSec well enough to write a connection config yourself.
Using kubectl port-forward might be an easier solution.
I have a VM instance (e2-micro) on GCP running with postgres. I added my own external ip address to pg_hba.conf so I can connect to the database on my local machine. Next to that I have a nodeJS application which I want to connect to that database. Locally that works, the application can connect to the database on the VM instance. But when I deploy the app to GCP I get a 500 Server Error when I try to visit the page in the browser.
These are the things I already did/tried:
Created a Firewall rule to allow connections on my own external ip address
Created a VPC connector and added that connector to my app.yaml
Made sure everything is in the same project and region (europe-west1)
If I allow all ip addresses on my VM instance with 0.0.0.0/0 then App Engine can connect, so my guess is that I'm doing something wrong the connector? I use 10.8.0.0/28 as ip range while the internal ip address of the VM instance is 10.132.0.2, is that an issue? I tried an ip range with 10.0.0.0 but that also didn't work.
First check if your app uses a /28 IP address range (see the documentation):
When you create a connector, you also assign it an IP range. Traffic
sent through the connector into your VPC network will originate from
an address in this range. The IP range must be a CIDR /28 range that
is not already reserved in your VPC network.
When you create a VPC connector a proper firewall rulle is also created to allow traffic:
An implicit firewall rule with priority 1000 is created on your VPC
network to allow ingress from the connector's IP range to all
destinations in the network.
As you wrote yourself when you create a rule that allows traffic from any IP it works (your app can connect). So - look for the rule that allows traffic from the IP range that your app is in - if it's not there create it.
Or - you can connect your app to your DB over public IP's - in such case you also have to create a proper rule that will allow the traffic from the app to DB.
Second - check the IP of the DB that app uses.
My guess is that you didn't change the IP of the DB (that app uses) and it tries to connect not via VPC connector but via external IP and that's why it cannot (and works only when you create a firewall rule).
This answer pointed me in the right direction: https://stackoverflow.com/a/64161504/3323605.
I needed to deploy my app with
gcloud beta app deploy
since the VPC connector method was on beta. Also, I tried to connect to the external IP in my app.yaml but that needed to be the internal IP ofcourse.
I have created a CloudSQL instance which was part of a VPC I have created.
I'm able to connect to this CloudSQL using CloudSQL Proxy service. But I'm unable to connect to this instance using public IP of the instance though I added the firewall rule to this VPC.
The error I'm getting:
Unable to connect to host <public-ip-of-cloudsql>, or the request timed out.
Be sure that the address is correct and that you have the necessary privileges, or try increasing the connection timeout (currently 10 seconds).
MySQL said:
Can't connect to MySQL server on '<public-ip-of-cloudsql>' (4)
Following is the firewall rule I added and provided my home IP address in the blocked out area.
Please let me know if I'm missing something. I can provide more details if needed.
These are the steps you should follow in order to connect to Cloud SQL using the public IP:
Created a Cloud SQL instance, including configuring the default user.
Assuming you use a local client:
2.Install the client.
3.Configure access to your Cloud SQL instance.
4.Connect to your Cloud SQL instance.
You can find a detailed explanation here: Connecting MySQL client using public IP
If you are using the Cloud SQL proxy to connect via public ip, it requires port 3307 to be open to the address.
If you aren't using the Cloud SQL proxy to connect via public ip, you need to authorize your external IP.
I was able to connect CloudSQL which is part of a VPC by just adding the client IP address as Authorized networks.
It's weird, I tried many times before but couldn't succeed. It is working now.
Thanks, guys for answers.
I plan to set the Secure Gateway Client at DMZ at on-premise environment, so I need to open Outbound ports for SG Client to connect to SG on Bluemix. The following question is similar to my question, but the answer doesn't show the needed ports.
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
The following Bluemix Doc shows Outbound 443 is needed.
https://www.ng.bluemix.net/docs/troubleshoot/SecureGateway/ts_index-gentopic1.html#ts_sg_006
What are the best practices for running the Secure Gateway client?
Before you install the Docker client into your environment, ensure that both the internet and your on-premises assets are accessible and all host names are resolvable by a DNS. The client uses outbound port 443 to connect to the IBM Bluemix environment, normally this port is open since its secure. Ensure you check or modify additional firewall and IP Table rules that might apply.
But, the tcpdump, which I got when I executed "docker run -it ibmcom/secure-gateway-client XXXX", showed that SG Client used Outbound 443 and 9000. Is it collect that all ports SG Client uses are Outbound 443 and 9000 ?
Correct, if you are closing down both outbound and inbound ports using your firewall, then for outbound allow ports 443/9000. So your initial assertion is correct.