Background
I have two Google Cloud VPC networks. VPC A and B. B network was peered into A network.
The VPC A has a NAT gateway with connectivity to the internet.
Instances running in VPC B has no internet connectivity.
Question
I want to connect VPC B to use A NAT in order to get internet connectivity.
How to do it?
As per VPC Network Peering interaction this isn't possible:
Cloud NAT gateways are associated with subnet IP address ranges in a single region and a single VPC network. A Cloud NAT gateway created in one VPC network cannot provide NAT to VMs in other VPC networks connected by using VPC Network Peering, even if the VMs in peered networks are in the same region as the gateway.
It is possible to achieve the result you are looking for by using a Shared VPC instead of VPC Network Peering, this would allow an organization to connect resources from multiple projects to a common VPC network.
Here you have be the steps you need to follow to create a Shared VPC.
Related
Question is really simple, Where we can check in the VPC to find internet-facing resources?
There are 1 VPC and it has couple private subnets where EC2 instances are in (with security groups attached), couple public subnets where NAT gateways are in (with EIP addresses attached) and each subnets has its own route table.
Note that there are 1 Internet gateway and 1 Virtual private gateway attached to VPC.
One way is to check for the resources in the public subnet. Another way is to capture the VPC network metadata using the VPC Flow logs and analyze the same using Athena. Here is a blog on AWS around the same. Another way is to use the VPC Ingress Routing.
I have a hub and spoke model for infrastructure with a management vpc and 4-5 different environment vpc, peered to the management vpc.
I already have it set up but currently I only have 1 nat instance and 1 bastion host. Both of which are in the management vpc public subnet.
I wish to connect an instance in an environment vpc in a private subnet to this NAT instance to be able to reach the internet. Is that possible?
Note: I have the NAT/Bastion working correctly in the management vpc. I can reach all servers in both vpc with the Bastion host. I just can't get the above working.
My question is... is it possible? or do I need to set up an NAT in every vpc?
Edge to edge routing through a gateway (including the VPC Internet Gateway or IGW) is an unsupported VPC configuration with VPC peering.
Example: Edge to Edge Routing Through an Internet Gateway
Let's say you have a VPC peering connection between VPC A and VPC B (pcx-abababab). VPC A has an internet gateway; VPC B does not. Edge to edge routing is not supported; you cannot use VPC A to extend the peering relationship to exist between VPC B and the internet. For example, traffic from the internet can’t directly access VPC B by using the internet gateway connection to VPC A.
Similarly, if VPC A has a NAT device that provides internet access to instances in private subnets in VPC A, instances in VPC B cannot use the NAT device to access the internet.
Transit Gateway seems to fit for the case.
Transit Gateway Example: Centralized Router
The following diagram shows the key components of the configuration for this scenario. In this scenario, there are three VPC attachments and one Site-to-Site VPN attachment to the transit gateway. Packets from the subnets in VPC, A, VPC B, and VPC C that have the internet as a destination, route first through the transit gateway and then route to the VPN.
We have a vmware instance hosted in our DataCentre, from which we have a AWS Direct Connect into a VPC in eu-west-2, and from there we've setup VPC peering to a different AWS account VPC in eu-west-1, as follows:
DataCentre <-- Direct Connect --> AWS London <-- VPC Peering --> AWS IE
The Direct Connect advertises the AWS London's VPCs private IP range via BGP (172.20.0.0/16). The Direct Connect is working fine, traffic between our DataCentre and this private IP range traverses the connection correctly. Similarly the VPC Peering is working correctly, I can send traffic directly instances in London (172.20.0.0/16) to instances in IE via their private IP range (172.31.0.0/16).
I want to route traffic from our DataCentre to instances in the AWS IE region over the Direct Connect and utilising VPC Peering. Specifically sending/receiving packets to a 172.31.0.0/16 IP from the VMWare instance. Can this be achieved solely with static routes?
Problems I'm hitting:
The Direct Connect BGP seems to only advertise the VPC IP range to which it's attached, not the peered range.
Direct Connect Gateway looks to do what I need but my setup involves multiple AWS accounts so I don't believe this is a viable option.
VPC peering does not support transit connections originating from other sources. They only support point-to-point connections, which is the reason DX BGP is advertising VPC range and not peered VPC range.
DX Connection or DX-Gateway doesn't support transitive routing.(i.e VPC A and VPC B are peered and VPC A is connected via DX directly/DX-Gaetway,though it seems to be indirectly connected it doesn't allow to connect to VPC B via DX by default)
Direct Connect Connections doesn't support across regions but do support multiple accounts with same region. (i.e DX location in eu-west-2 in one account can support multiple accounts for the same eu-west-2 region via Hosted VIF definition)
With DX-Gateway your existing DX connections can now be used across multiple regions and multiple accounts. (Note:- From June 2019 I guess DX-Gateway can support multiple accounts)
Try out Transit Gateway and DX-Gateway combination to simplify your networking architecture.
I have a private M2M GSM network for my company devices.
I want to send traffic from my devices to AWS IOT but the M2M provider doesn't allow internet access from its sim cards, it only provide an IPSec connexion to a a private network.
I had now problem configuring the IPSec connexion to an AWS VPC and my sims can successfully ping all instance in my AWS VPC. However what I want is for my sims to access AWS IOT.
What I did:
I configured my VPN with AWS third scenario. I have a public network with CIDR 192.168.0.0/24 and a private network with CIDR 192.168.1.0/24. My VPN has a static route CIDR 10.1.128.0/14 for my M2M network.
Then I launched an EC2 Nat Instance inside my public network.
I added a routing rule to my VPC main routing table to route trafic to 0.0.0.0/0 to my NAT instance.
I launched an EC2 instance in my VPC's private network and try to access internet from it, this work and I can see trafic going throung my nat instance. So I assume my nat and routing is well configured.
However I still can't manage to access internet from my sim cards, traffic isn't even routed to my NAT instance. According to John Rotenstein's answer VPN traffic will not use my routing rule.
Does AWS VPN drop traffic which is not destinated to the VPC's or VPN's CIDR ? Is there a security reason for that ?
If that's the case is there a way to customize routing rules for the VPN's traffic ? Or is the only solution to use a custom VPN within an EC2 instance ?
Thank you for your help.
I added a routing rule to my VPC main routing table to route trafic to 0.0.0.0/0 to my NAT instance.
It is an understandable misconception that the "main" route table of a VPC impacts traffic coming in from a VPC hardware VPN. It doesn't. There is no route table that applies to such traffic, only the implicit target of the VPC subnets. Only the assigned CIDR blocks can be reached from such a VPN.
Does AWS VPN drop traffic which is not destinated to the VPC's or VPN's CIDR? Is there a security reason for that?
Yes, that traffic is dropped.
It probably not specifically for security reasons... it's just the way the service was designed to work. Managed VPN connections are intended for access to instance-based services, and don't support traffic flows we might generally categorize as gateway, edge-to-edge, peering, or transit.
If you can configure your edge devices to use a web proxy, then a forward proxy server like squid could handle the connectivity for the devices, because the IP path between a device and a forward proxy is a connection involving only the device and proxy IPs.
A simpler solution would be to use an instance-based firewall to terminate the VPN, instead of the built-in VPC VPN service, because then the firewall instance could allow the traffic to hairpin through itself, source-masquerading (NAT) the traffic behind its own EIP, and this would be something the VPC infrastructure easily supports.
An instance-based firewall is something you can build yourself, of course, but there are also several products in the AWS Marketplace that provide IPSec tunnel termination and NAT capability. Some have free trial periods where the only cost is the cost of the instance.
Google Cloud & AWS have different implementation for a VPC. In GCP VPC are associated with projects. What's confusing me is that in a GCP project you can have two different VPC but with same subnet CIDR. If anyone has any resource which can clear my doubts please
In GCP, 2 VPC networks in the same project must have different names, so they are distinguishable and completely independent/isolated. VMs in one VPC network have to go through external IP addresses to talk to VMs in other VPC network. Or you can connect them through VPC Peering, so that they can talk to each other through internal IPs. See:
GCP - VPC Network Overview.
GCP - VPC Network Peering
A feature you can use in this case is to create a Peering in the VPC, this function will allows internal IP address connectivity across two Virtual Private Cloud (VPC) networks regardless of whether they belong to the same project or the same organization.
VPC Network Peering enables you to connect VPC networks so that workloads in different VPC networks can communicate internally. Traffic stays within Google's network and doesn't traverse the public internet.
VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including: Network Latency,Network Security and Network Cost.
For information about Peering and VPC,see:
VPC: https://cloud.google.com/vpc/docs/vpc
Peering: https://cloud.google.com/vpc/docs/vpc-peering