Static Routing over Direct Connect and VPC Peering - amazon-web-services

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.

Related

Can I use an AWS Client VPN endpoint to access more than three subnets in the same region?

My VPC is in eu-west-2. I have two subnets for an RDS instance, split across two different availability zones for reasons of high availability: eu-west-2a and eu-west-2b. I also have a Redshift cluster in its own subnet in eu-west-2c.
With this configuration, I have successfully configured an AWS Client VPN endpoint so that I can access RDS and Redshift from my local machine when connected to a VPN client with the appropriate configuration.
While following the same principles of using subnets for specific services, I would like my EC2 instances to live in private subnets that are also only accessible over a VPN connection. However, one of the limitations of the Client VPN service is:
You cannot associate multiple subnets from the same Availability Zone with a Client VPN endpoint.
This implies that I would need to create a separate endpoint for connecting to my private EC2 subnet—which feels like complete overkill for my modest networking architecture!
Is there a workaround?
By default, a subnet can reach the other subnets.
This means that you won't need to do anything. This will work out of the box. If not, check the route tables and see if there is a route from your VPN subnet to your private subnet.
When you associate the first subnet with the Client VPN endpoint, the following happens:
The state of the Client VPN endpoint changes to available. Clients can now establish a VPN connection, but they cannot access any resources in the VPC until you add the authorization rules.
The local route of the VPC is automatically added to the Client VPN endpoint route table. (This local route allows you to communicate with every subnet within the VPC that the subnet is in.)
The VPC's default security group is automatically applied for the Client VPN endpoint.
See documentation for details.

What is the difference between VPC Peering and VPC Endpoint Service? And when to use them?

I understand VPC Peering is used to establish connection between 2 VPCs. And to connect to another Application/Service in another VPC, VPC Endpoint Service is used. But can't a VPC Endpoint Service be connected via VPC peering?
A use-case/scenario will help
You can find a lot of info on VPC peering here:
https://docs.aws.amazon.com/de_de/vpc/latest/peering/what-is-vpc-peering.html
It is, like you already said - a (network) connection of two VPCs.
A VPC Endpoint gives you some more options - you could say it is build on top of the VPC peering idea.
Here is a short articel about it:
https://catalog.workshops.aws/networking/en-US/intermediate/5-vpc-endpoint-services/10-vpc-endpoint-services-overview
It also menntions some use cases, like
Application in a VPC that has no VPN or TGW access to other VPCS.
Application in a VPC which has overlapping IP addresses with the VPC you want to share it with
Sharing an application with external consumers in other AWS accounts (even via MarketPlace)
Limit the firewall rules for access to an on premise application by using Privatelink as a single point of access for all VPCs in a region

How to access the internet via other VPC NAT?

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.

Connect a third party VPC with existing VPC Network Peering setup - GCP

I've two VPCs network connected via VPC Network Peering. How can I connect another VPC which is not within GCP? I reckon I have to use Cloud VPN to connect the three?
Do I have to disable the existing VPC Network Peering before I can set up Cloud VPN? Is there a better way to connect the three?
To connect to an on-premise network, you have to use Interconnect or Cloud VPN.
These services are totally compatible with the VPC Peering that you've already created, and if you define the routing correctly, you'll be able to reach from the on-premise the two VPCs and vice-versa.

NAT AWS VPN to AWS IOT via VPC

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.