By using AWS re:Post, you agree to the Terms of Use

OpenVPN client IP will not route accross VPC Peering

0

I have two OpenVPN servers in two separate regions. Region A OpenVPN IP =172.16.0.2/24 and Region B OpenVPN IP = 172.17.0.2/24 . Region A OpenVPN clients (on the Internet) Poll of IP is 10.55.55.0/24 and Region B OpenVPN clients (on the Internet) Poll of IP is 10.66.66.0/24 With my VPC Peer route tables, I have told it to route 10.66.66.0/24 to Region B and Also in Region B I set it to route that subnet to the OpenVPN EC2 adapter. I have basically done allow All for the various VPC groups and ACL. When I try to ping a VPN client in Region B from Region A I see the packet leaving the OpenVPN adapter then it goes into oblivion. I have turned off the source/destination check and have verified my Openvpn IPtables. I also tried putting the Region B machine into the same subnet as Region A and when both OPENVpn servers were in the same subnet there's no problem. Can you route an IP range across a Peer to a machine interface when the IP range (on the OpenVPN client) does not exist in the VPC's subnet's CIDRs?

Any thoughts would be appreciated. Thank you so much.

asked 5 months ago71 views
2 Answers
0

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.

profile picture
EXPERT
answered 5 months ago
  • 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.

0

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.

answered 5 months ago
  • My plan is to build this out but (apologies) I haven't had a chance to test it yet.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions