My AWS VPN setup results in no traffic working when connecting - amazon-web-services

I have created a VPN to our VPC but when I connect to it from my machine, nothing works - neither Internet, nor can I reach VPN-internal endpoints.
I added public dns-servers and split-tunnel=enabled to the configuration.
The VPN is set to
`Client IPv4 CIDR 10.10.0.0/16`
An association has been added (line from AWS console):
cvpn-assoc-<id> subnet-<id> cvpn-endpoint-<id>  Associated sg-<id>
There are two authorization rules (one allowing everything until I get it working)
The route table looks like this (was automatically added via the assoc):
cvpn-endpoint-<id> 10.1.0.0/16 subnet-<id> Nat associate  Active Default Route
This RT is the only thing which looks odd. In the VPC, the subnet has a definition of 10.1.0.0/24 - but the automatic association sets it to 10.1.0.0/16. But there's actually no way to set it to 10.1.0.0/24 in the routing table, doing so results in an error about the range being invalid.
I also tried creating the VPC with a client IP CIDR of 10.10.0.0/24 but then it errored saying it must at least be /22.

Related

Google Cloud Platform Reserved Address Space in VPC Network Route

I need to add a route in GCP's VPC Network and when I do, I get an error (shown below) that appears to state there is an overlap/conflict with the 10.130.0.0/16 range. I unfortunately do not see this 10.130.0.0/16 in any route, in any region and I have no idea why this error is occurring.
Creating route "test" failed. Error: Invalid value for field 'resource.destRange': '10.130.90.82/32'. 10.130.90.82/32 hides the reserved address space for network (10.130.0.0/16).
I have tried adding this simple route in several gcp projects but they all fail and seem to imply there might be some hidden reserved address space. Could this be? What am I missing? This occurs with any route destination value that is in the 10.130.0.0/16 space eg; 10.130.90.82/32 10.130.90.0/24
For clarification here is an example Route that fails:
Additional Clarification, Here is the 'default' VPC Network:
Google Cloud does not allow you to create a new subnet or peering subnet route whose destination exactly matches or is broader than (would contain) an existing custom static route. For example, if your VPC network has a custom static route for the 10.70.1.128/25 destination, Google Cloud prohibits the creation of any subnet or peering subnet route with a primary or secondary subnet IP address range of 10.70.1.128/25, 10.70.1.0/24, or any other range that contains all the IP addresses in 10.70.1.128/25.
Kindly check Configuring private services access docs. Included on the docs are the considerations , Creating an IP allocation, Deleting an allocated IP address range etc.
There is in fact a hidden reserved address space in the default VPC network. I hesitate calling hidden as JaysonM mentioned it in his answer but it does not appear anywhere in the GPC console (to my knowledge).
The default VPC network is using 'auto' subnet creation mode. With this setting enabled the VPC network has a range of 10.128.0.0/9 (10.128.0.0 - 10.255.255.255) that cannot be overlapped. Simply setting 'auto' subnet creation of the VPC network to 'custom' will resolve this issue. Do also note this is a one-way change for your VPC network.
Cheers!

Cannot connect to AWS Transfer S3 SFTP server - might need to set security group

I'm trying to set up an SFTP server managed by AWS that has a fixed IP address which external clients can whitelist in a firewall. Based on this FAQ this is what I should do:
You can enable fixed IPs for your server endpoint by selecting the VPC endpoint for your server and choosing the internet-facing option. This will allow you to attach Elastic IPs (including BYO IPs) to your server’s endpoint, which is assigned as the endpoint’s IP address
So I followed the official instructions here under "Creating an Internet-Facing Endpoint for Your SFTP Server". The creation settings look like this:
The result looks like this:
Compare with the result screenshot from the docs:
(source: amazon.com)
My result is almost the same, except that under the table "Endpoint Configuration" the last column says "Private IPv4 Address" instead of 'Public'. That's the first red flag. I have no idea why it's a private address. It doesn't look like one, it's the IP address of the Elastic IP that I created, and the endpoint DNS name s-******.server.transfer.eu-west-1.amazonaws.com resolves to that IP address on my local machine.
If I ping the endpoint or the IP address, it doesn't work:
451 packets transmitted, 0 received, 100% packet loss, time 460776ms
If I try connecting with sftp or ssh it hangs for a while before failing:
ssh: connect to host 34.****** port 22: Connection timed out
Connection closed
The other potential problem is security groups:
At this point, your endpoint is assigned with the selected VPC's default security group. To associate additional or change existing security groups, visit the Security Groups section in the https://console.aws.amazon.com/vpc/.
These instructions don't make sense to me because there's nowhere in the Security Groups interface that I can assign a group to another entity such as a transfer server. And there's nowhere in the transfer server configuration that mentions security groups. How do I set a new security group?
I tried changing the security group of the Network Interface of the Elastic IP, but I got a permission error even though I'm an administrator. Apparently I don't actually own ENIs? In any case I don't know if this is the right path.
The solution was to find the endpoint that was created for the server in the "Endpoints" section of the VPC console. The security groups of the endpoint can be edited.
The "Private IPv4 address" seems to be irrelevant.
The default security group controls access to the internet-facing endpoint for the new sftp server in a vpc. Mess around with the default security group ingress rules for the vpc selected for the sftp server. Or, white list the exact ip address connecting to the sftp endpoint in the default security group.
If the admin says ho hum, create a second vpc for the sftp server if isolation is absolutely necessary. Fiddle with the default group in the new, isolated vpc.
Link:
Creating an Internet-Facing endpoint for Your sftp server
Happy transferring!

Cannot create a classic route based VPN tunnel with Terraform in GCP

What I want to accomplish:
I want Terraform to create a Classic route based VPN tunnel in GCP.
Background:
When setting up a VPN tunnel in GCP there are three options for routing
BGP
Route based
Policy based
When creating a Route based VPN tunnel in GCP you need to specify the remote subnets. If you are creating a Policy based VPN tunnel you also need to specify local subnets.
Since I want to create a route based VPN tunnel I only need to provide remote subnets.
The problem:
However in Terraform, there is no option for the resource "google_compute_vpn_tunnel" that has to do with what routing type to use.
Okay maybe its determined by the lack of "local_traffic_selector" and then becomes a route based VPN tunnel.
But even if I ommit the "local_traffic_selector" option in my main.tf it is still there in the plan.
' + local_traffic_selector = (known after apply)
Since I have not specified any value for it, Terraform tries to use it with an empty value, which is not possible.
Error: Error creating VpnTunnel: googleapi: Error 400: Invalid value for field 'resource.localTrafficSelector[0]': ''. The local_traffic_selector field cannot be empty for network in custom subnet mode., invalid
on main.tf line 51, in resource "google_compute_vpn_tunnel" "tunnel1":
51: resource "google_compute_vpn_tunnel" "tunnel1" {
If I do specify it, the VPN tunnel will be of type Policy based instead of Route based.
Is there no support for Terraform to create a route based classic VPN tunnel in GCP?
Another strange thing is when creating the VPN gateway. When you do it in the GCP console you need to specify what external IP address the VPN gateway have. That is a pretty important property. But Terraform has no option for setting the IP address for the resource "google_compute_vpn_gateway"
In the examples here: https://www.terraform.io/docs/providers/google/r/compute_vpn_gateway.html they create an static IP object, but its never assigned to the VPN gateway in the configuration.
According with the documentation of VPN routing policies, the Route Based = Policy based if the local selector is in 0.0.0.0/0
Route based VPN tunnels are similar to tunnels that use policy based routing, except that only the remote IP ranges (right side) are specified. The list of local IP ranges is assumed to be any network (0.0.0.0/0), so you only specify the remote traffic selector.
By the way add local_traffic_selector= ["0.0.0.0/0"] in your tunnel definition, like this (here in the default example of Terraform)
resource "google_compute_vpn_tunnel" "tunnel1" {
name = "tunnel1"
peer_ip = "15.0.0.120"
shared_secret = "a secret message"
local_traffic_selector= ["0.0.0.0/0"]
...
Yes, of course, the created VPN tunnel is set as Policy Based in the GUI but with a local network to 0.0.0.0/0, thus technically equivalent to Route Based config.
About the static IP, it's the standard (and boring) behavior of Terraform. You have to create the static IP with Terraform, for having the state saved in TFSTATE file, and then having the capability to reuse it.
Try this:
Keep only the external ip creation in your main.tf file
resource "google_compute_address" "vpn_static_ip" {
name = "my-vpn-ip"
}
Apply this configuration
Now add the rest of the configuration
Apply again the update of the configuration
As you could see, Terraform retrieve the IP from the previous state and reuse it without creating a new IP.
google_compute_address.vpn_static_ip: Refreshing state... [id=******PROJECT_ID*****/us-central1/my-vpn-ip]
resource "google_compute_vpn_tunnel" "tunnel1" {
name = "tunnel1"
peer_ip = "15.0.0.120"
shared_secret = "a secret message"
local_traffic_selector= ["0.0.0.0/0"]
remote_traffic_selector=["0.0.0.0/0"]
Add remote_traffic_selector field as 0.0.0.0/0 and create routes pointing to tunnel independently it will create route based VPN.

Instances of Amazon AWS EC2 have no Internet / misconfiguration?

I am able to connect to my Amazon AWS EC2 instances (Ubuntu) via SSH, but the Instances self can not connect to the Internet, what I noticed when doing
sudo apt-get update
that leads to a timeout. I have drawn a diagram of the current VPC configuration and hope that someone can tell me what is wrong:
I already controlled Inbound and Outbound rules but I cannot see something.
Can someone help me and tell what problem do I have? Is it maybe that the VPC CIDR has suffixmask 16 and the Subnet CIDR has suffixmask 20 or something like that?
By the way - I can not remember that I have changed something here.
VPC "vpc-cf8f91a4"
==================
My VPC-ID is vpc-cf8f91a4
The IPv4 CIDR is 172.31.0.0/16
Route table: rtb-f0da499a
Network ACL ID: acl-05e2486f
Internet Gateway "igw-a6b7aace"
===============================
igw-a6b7aace associated with vpc-cf8f91a4
Associated 2 Subnets
====================
subnet-faefd387 172.31.32.0/20 associated with route table rtb-f0da499a
subnet-febe7f94 172.31.16.0/20 associated with route table rtb-f0da499a
Route Table "rtb-f0da499a"
Destination | Target | Status | Propagated
172.31.0.0/16 | local | active | No
0.0.0.0/0 | igw-a6b7aace | active | No
As stated in one of the comments ACLs are an advanced feature and it's not recommended to use them unless you're familiar with the lower levels of the network stack and have a reason to use them, e.g. working in a highly secure environment, or need role separation such as network and development teams.
From the information you have provided the most likely issue is that you are blocking ephemeral port return traffic with your ACL. ACLs are stateless so you must allow return traffic.
For most tcp connections this means 1024-65535, if you add that as an inbound ACL rule and retest.
As a side note, you should not allow the internet to access your database, this is very bad practice. I would recommend you create another subnet that is private (no IGW route) and put the database in there, and do not give it a public IP address.

When I ping the RDS endpoint from my computer it shows the Private IP of the RDS

We are trying to configure a VPC, which has a private subnet and a public subnet. In the private subnet there is an RDS which is not publicly accessible. We have test it and seems that works fine! The issue though its that when I ping the RDS endpoint from my computer it returns the Private IP of the RDS (its not returns any packets though).
We do not want to shows the Private IP.
Any help would be appreciated!
I went ahead and popped open a chat with our AWS support team to pick their brain. Basically, this boils down to how they host their DNS mappings for RDS endpoints; they're created in a public hosted zone by default (not modifiable). Hence, you can resolve your RDS endpoint over the internet (because the mapping is hosted publicly), but can't actually route any data to it.
If this is an issue, to get around it you can ... jump through some hoops:
An alternative will be to create a private hosted zone with a record
that points to the rds endpoint. (for example a private hosted zone
"xxxx.com" that has an alias record pointing to rds endpoint), in which case you will reach out to your rds instance
using xxxxx.com
However, this doesn't actually disable the original AWS created endpoint from returning the private IP, it just allows you to configure an endpoint that doesn't.
For what it's worth, revealing your private IP is pretty harmless; several thousand devices likely share your exact private IP. The only way this information would be concerning for you is if an attacker was actually in your network - and at that point... they could just do a lookup on the DNS from there to get the IP.
First question: why do you want to do this? Your 10.1.2.3 or 172.31.2.3 or whatever is a non-routable address. It really doesn't matter whether people know it if they can't get into your VPC.
As for actually preventing it, you can't: Amazon makes the endpoint available via DNS (you can use nslookup to find it). You could always try filing a support ticket, but I wouldn't expect any results.
Also, FYI the second component of the endpoint is related to your account. So in your image you redacted non-important information but left the (potentially) important information present.
In case it's not clear, the problem is in how Amazon resolves DNS requests, not in how the networks are connected. Here's an example of an nslookup call for one of our database instances that's running on a private subnet. This is from my PC, not connected to the VPC via VPN or any other means:
> nslookup REDACTED.REDACTED.us-east-1.rds.amazonaws.com
Server: 127.0.1.1
Address: 127.0.1.1#53
Non-authoritative answer:
Name: REDACTED.REDACTED.us-east-1.rds.amazonaws.com
Address: 10.1.56.119