Avatar of exptech
Flag for United States of America asked on

AWS Managed VPN problem

I need help with static routing for an AWS managed Vpn connection to a either a Greenbow VPN client or another AWS VPC. I am a developer, not a network engineer, but I have set up both hardware and software VPNs in the past, just never AWS managed. I know the easiest way is to just peer the VPCs together but that is not how we want to set it up. First off I am not sure if you can even connect two VPCs using the AWS managed VPNs. From what I have read they can not initiate connections, only receive them so manged to manged may not be possible.  We tried setting up a Greenbow VPN client on a VPC with no manged VPN connection and when we try to connect we are able. The problem is that we can not ping any machines. All firewall rules are configured properly ( we can ping using the external IPs). Basically we have the windows firewalls turned off and the AWS security groups allowing all traffic between the two VPCs. Here is where I believe the problem is and it comes with question. We set the VPN connections to use static routing and added a route to the managed VPN subnet routing table specifying the subnet that the Greenbow client is in and used the managed gateway as the target. On the Greenbow side we configured it with the subnet we want to reach on the managed VPN side. so Here is an example to make it more clear:

Our side of the VPN (the one with the Managed VPN connection) subnet: mask
Client side of the VPN (the one with the Greenbow client) subnet: mask

We created a customer gateway with the client external ip (won't specify it for obvious reasons)
We then created a Virtual Private Gateway and attached it to our VPC.
We then created a VPN connect specifying the customer gateway and the virtual private gateway. We chose static routing and allowed AWS to chose the preshared key as well as the Inside IP Tunnel CIDR.

We then created a static route for the subnet as follows :  Destination : Target: we chose the virtual private gateway we set up.

The client used the managed VPN external ip and entered all of the security config details we gave them for the tunnels. In the Greenbow client for the destination they chose subnet as the type and entered the following : mask

Then then attempted to connect. The greenbow logs showed the connection and sent acknowledgements and got replies. The vpn connection on our side showed "UP", but we can not reach any systems on either side.

Here is where I think the problem may be and an excerpt from the AWS config file we downloaded for the connection:

To route traffic between your internal network and your VPC,
you will need a static route added to your router.

Static Route Configuration Options:

  - Next hop       :
You should add static routes towards your internal network on the VGW.
The VGW will then send traffic towards your internal network over
the tunnels.

This is the internal IP CIDR according to AWS. I have no idea what this is and what they want us to do. Normally when setting up a VPN you just specify the subnets on both sides and all works well. I have never seen this and like I said I think this might be the problem. Please if anyone can enlighten me that would be awesome.

Thanks in advance

Avatar of undefined
Last Comment

8/22/2022 - Mon
Phil Phillips

Is there a particular reason why you don't want to use VPC peering for this?  It'll make the setup a lot easier, and it's essentially a VPN behind the scenes (AWS encrypts traffic between peered VPCs).

Thanks for responding Phil. Unfortunately the client also has a network that is not on AWS but hosted by a completely different cloud provider and we don't want to maintain different solutions. In addition most of the other VPNs we will be setting up involve clienswho have networks that are local in their offices not in clouds. So we really need to work this issue out for the future as well. By doing this we will have a better understanding of the AWS Manged VPN.
Phil Phillips

The last step you mentioned (static routing configuration) allows the traffic to flow through their Virtual Gateway.

So, it looks like on the client network, you need a static route for with a next hop of

Also, make the VPN connection on the AWS side has the route as well:
  • VPC page -> VPN Connections -> VPN Connections
  • Select your vpn connection
  • Static routes tab
  • Make sure there's an entry for
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.

That is what I thought but that presents a new issue. How would you set up the static route in a software client like Greenbow. When I make a connection to the server with the client and looked at the routing table for the windows machine hosting the client and here is where I am getting confused. The Greenbow client creates a virtual network interface with an ip of and a gateway of Now that being said what route would I add to the windows machine since my understanding of the next hop would be the gateway ( but to go through the VPN client the gateway is Could you give me a sample Route ADD command with these parameters?

Maybe this is not possible with this client, if not can you recommend one for windows machines.

If the client is not using a software VPN client then I assume you would add the route to the Edge router of their network, correct?
Phil Phillips

I'm looking at my own config, and I actually don't see that static route. Though, it is a hardware setup, so things could be a bit different there...

Could you confirm that you at least do have the static route set up on the VPN connection on AWS' side?  (See last note in my previous comment).

Sure Phil, here is a copy of the routing table for the subnet inside the Managed VPN VPC :

Route Table
While waiting I also tried to setup a connection using another server running Windows 2008 Server R2. For testing purposes this server is not running the Greenbow client. Instead I am using the native routing and remote access built into the server. I followed AWS example and even ran their netsh script to be sure I did not make a configuration error. Here is what I ran (from the downloaded AWS config file for Windows 2008 Server R2):

! Netsh script to configure your IPsec VPN connection
! --------------------------------------------------------------------------------
! You can automatically configure your IPsec VPN connection by copying and pasting
! the netsh scripts below. Replace the items in brackets [] with the appropriate
! values as discussed above.

! Script for Tunnel 1:
netsh advfirewall consec add rule Name="vgw-84ee18ed Tunnel 1" ^
Enable=Yes Profile=any Type=Static Mode=Tunnel ^
LocalTunnelEndpoint= ^
RemoteTunnelEndpoint=[ManagedVpnPublicIP] Endpoint1= ^
Endpoint2= Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=[PresharedKey] ^
QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^
ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2

I substituted the following (real values not show for obvious reasons):

[ManagedVpnPublicIP] = The public IP of the Managed VPN side
[PresharedKey] = The preshared key

The result is the same. I am not sure if there are any AWS logs I can check. I have never had such a problem setting up a VPN in the past and that has been quite a few (both hardware and software based). As I said though I am a developer, not a network engineer. For testing purposes I turned off the Windows firewall on both systems and allowed all traffic in their AWS security groups (not a risk since it was for a very short time and they are both clean test systems).
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Phil Phillips

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.

I have that entry as well. This is really crazy, it should work but does not. I have to finish a project today but tonight I am going to go over every setting with a fine tooth comb and I will post the results.
Phil Phillips

Yeah, it looks like everything is in order, especially with the link reporting as UP. When you're going over it with a fine tooth comb, some other things I can think of to double check:

  • Security groups on the instances you are trying to reach
  • Network ACL for the subnet the instances are in (found in VPC->Security->Network ACLs)

Just a quick response to the security groups and Network ACLs. For testing purposes (a very short time) I allowed all traffic (both directions) in the instance security groups and the network ACLs.
Your help has saved me hundreds of hours of internet surfing.

Sorry about the delay had an illness in the family.