Join Log in
Score:0
mreferre avatar Server

OpenVPN on AWS (works in NAT mode but doesn't work in Routing mode)

nl flag
mreferre

I have a brand new VPC (10.0.0.0/16) with 3 public subnets (pointing to an IGW) and 3 private subnets (with a NAT GW in each). I have deployed an OpenVPN appliance in the public subnet and configured it to use NAT mode (Yes, using NAT in the routing config). I also have a test-instance in one of the private subnets. Both the OpenVPN instance and the test-instance has SG groups with "generous" flexibility (i.e. everything allowed in-out.... for test purposes). On the OpenVPN I have configured 10.0.0.0/16 in the Specify the private subnets to which all clients should be given access (one per line): field.

From my Mac (on a home network 192.168.178.0/24) I can establish a tunnel and I can easily get to the test-instance. All good.

Now I want to switch to Route mode.

  • I changed the routing mode to Yes, using Routing. I disabled the source/destination check on the OpenVPN instance.
  • I added a static rote to all 4 routing tables in the VPC (3 x the private subnets and 1 x the public subnet) to say that traffic directed to 192.168.178.0/24 (my home network) should go to the OpenVPN instance (probably this was not required for the public subnet).
  • I added 192.168.178.0/24 to the Specify the private subnets to which all clients should be given access (one per line): field (not sure if this was required) in addition to 10.0.0.0/16.
  • I have reconfigured the user permissions for the user I am using to login with Use Routing and specifying again both subnets above (10. and 192.).

I can still establish the tunnel. I can reach the internal IP of the OpenVPN instance:

$ traceroute 10.0.4.223          
traceroute to 10.0.4.223 (10.0.4.223), 64 hops max, 52 byte packets
 1  10.0.4.223 (10.0.4.223)  178.345 ms  174.470 ms  173.680 ms
$

But I canNOT reach the test-instance in the private subnet:

$ traceroute 10.0.165.139
traceroute to 10.0.165.139 (10.0.165.139), 64 hops max, 52 byte packets
 1  172.27.232.1 (172.27.232.1)  194.976 ms  177.014 ms  174.402 ms
 2  * * *
 3  * * *
 4  * * *
^C
$

Interestingly, if I ssh into my OpenVPN server and I try to curl an NGINX on my local workstation where I started the tunnel I cannot reach it. It looks like the workstation can reach to the OpenVPN server (see the trace above to 10.0.4.223) but the OpenVPN server cannot reach to the workstation (for some reasons).

It looks like the flow initiated from the workstation is capable of finding a route to (and back from) to the OpenVPN instance. However the route breaks somewhere from the workstation to the test-instance (and back) AND it seems to be breaking also when initiated from the OpenVPN instance to the workstation (see the curl).

150
1 + 0
vpn
nat
Score:0
mreferre avatar Server
nl flag
mreferre

I eventually figured out that the OpenVPN Access Server appliance cannot be configured to connect back to the native IP of the client on the local subnet. However the client can be reached via the tunnel IP assigned by the VPN. This IP can be configured statically on a per user basis or it can come from a pool defined on the appliance.

In my case I have configured both (see picture).

enter image description here

It's important to know that this is (these are) also the subnets that needs to be used in the routing information. That is, an IP that sits in the 10.0.0.0/16 network can reach the client device to one of the 172.27 addresses assigned and so it's the 172.27 networks that need to be specified in the routing table (and NOT the local native network of the client device - 192.168.178.0/24 in my example).

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.