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: 172.31.0.0 mask 255.255.0.0
Client side of the VPN (the one with the Greenbow client) subnet: 172.35.0.0 mask 255.255.0.0
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 : 172.35.0.0/16 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 : 172.31.0.0 mask 255.255.0.0
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 : 169.254.44.69
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
Our side of the VPN (the one with the Managed VPN connection) subnet: 172.31.0.0 mask 255.255.0.0
Client side of the VPN (the one with the Greenbow client) subnet: 172.35.0.0 mask 255.255.0.0
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 : 172.35.0.0/16 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 : 172.31.0.0 mask 255.255.0.0
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 : 169.254.44.69
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
NetworkingAWSVPN
Last Comment
exptech
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).
ASKER
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.
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 172.31.0.0/16 with a next hop of 169.254.10.245.
Also, make the VPN connection on the AWS side has the route as well:
So, it looks like on the client network, you need a static route for 172.31.0.0/16 with a next hop of 169.254.10.245.
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 172.35.0.0/16
ASKER
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 10.10.10.10 and a gateway of 10.10.10.1. Now that being said what route would I add to the windows machine since my understanding of the next hop would be the gateway (169.254.10.245) but to go through the VPN client the gateway is 10.10.10.1. 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?
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?
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).
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).
ASKER
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=172.31
RemoteTunnelEndpoint=[Mana
Endpoint2=172.35.0.0/16 Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=[PresharedKey] ^
QMSecMethods=ESP:SHA1-AES1
ExemptIPsecProtectedConnec
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).
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=172.31
RemoteTunnelEndpoint=[Mana
Endpoint2=172.35.0.0/16 Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=[PresharedKey] ^
QMSecMethods=ESP:SHA1-AES1
ExemptIPsecProtectedConnec
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).
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
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.
ASKER
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.
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)
ASKER
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.
ASKER
Sorry about the delay had an illness in the family.