- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
I'm not convinced that this will work but a few more details are required:
When a VPN client connects and is allocated an IP address of 10.55.55.x - what is that client trying to connect to? A 10.66.66.x address? Or a 172.17.0.x address?
You mentioned that you've added routes in region B but have you also added the "opposite" routes in region A? Routing is a two-way process - adding the routes in one direction doesn't automatically make it work the other way around for return traffic.
I redid this with a whole 10.66.0.0/16 network and then put 10.66.66.0/24 on the VPN side and still the destination isn't getting routed through the Peering when I point it to the 10.66.0.2 adapter. I am convinced Peering isn't working and this is a bug.
My plan is to build this out but (apologies) I haven't had a chance to test it yet.
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 3 Jahren- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
Hey Brettski. Thanks for the reply. Sorry, I probably didn't think out my question well enough. I did put routes in both VPC's to send it to the peering connection. It seems like the Peering is doing something like src/dst checking. When I put a sniffer on either destination EC2 ens5 interface I don't even see the ICMP Echo hit it. I see it leave from the source ens5 however.
Here is the expected behavior. vpn client @10.55.55.2 <-> ast01(Openvpn1 ec2 machine)ens5/172.16.0.2 <-> VPC A main routing table <-> Peering Conention <-> VPC B Main Routing table <-> ens5/172.17.0.2 (Openvpn2 ec2 machine) ast0/10.66.66.1 <-> vpn client @ 10.66.66.2
VPC A routing table route 10.66.66.0/24 to Peering Route 10.55.55.0/24 to Openvpn1 ens5 adaptor
VPC B Routing Table Route 10.55.55.0/24 to Peering Route 10.66.66.0/24 to Openvpn2 ens5 adaptor
So in scenarios A to B I see the packet leave Openvpn1 ens5 but I don't see the packet even reach Openvpn2's ens5. It's like it's getting blackholed. I've checked the ACL's dozens of times before just putting in allow all and ICMP 0.0.0.0/0 for those. Also put allows in the VPC group security on both sides for those 10.x addresses and VPC subnet addresses. I imagine anyone could try adding a route to a nonexistent IP in the AWS network across A VPC to a destination EC2. You should still see a packet hit the destination interface? It doesn't seem too.
Hey Brettski. Thanks for the reply. Sorry, I probably didn't think out my question well enough. I did put routes in both VPC's to send it to the peering connection. It seems like the Peering is doing something like src/dst checking. When I put a sniffer on either destination EC2 ens5 interface I don't even see the ICMP Echo hit it. I see it leave from the source ens5 however.
Here is the expected behavior. vpn client @10.55.55.2 <-> ast01(Openvpn1 ec2 machine)ens5/172.16.0.2 <-> VPC A main routing table <-> Peering Conention <-> VPC B Main Routing table <-> ens5/172.17.0.2 (Openvpn2 ec2 machine) ast0/10.66.66.1 <-> vpn client @ 10.66.66.2
VPC A routing table route 10.66.66.0/24 to Peering Route 10.55.55.0/24 to Openvpn1 ens5 adaptor
VPC B Routing Table Route 10.55.55.0/24 to Peering Route 10.66.66.0/24 to Openvpn2 ens5 adaptor
So in scenarios A to B I see the packet leave Openvpn1 ens5 but I don't see the packet even reach Openvpn2's ens5. It's like it's getting blackholed. I've checked the ACL's dozens of times before just putting in allow all and ICMP 0.0.0.0/0 for those. Also put allows in the VPC group security on both sides for those 10.x addresses and VPC subnet addresses. I imagine anyone could try adding a route to a nonexistent IP in the AWS network across A VPC to a destination EC2. You should still see a packet hit the destination interface? It doesn't seem too.