1

We're migrating to a new jump host, migrating from a machine in-house. We also have 100+ customers that we will still need to communicate with via SSH. Their firewalls currently allow our primary office in via SSH, but not our AWS host. It takes time to migrate 100+ customers' firewalls, so until that is finished, we want to route all traffic for these IPs over a VPN that's already established so the traffic exits from our office and not the Internet Gateway (IGW) on Amazon.

I'm missing a few details in my education with regard to routing, so if someone could explain this to me, that would be great...

The VPC has this routing table:

0.0.0.0/0 -> igw
172.31.254.0/24 -> local
172.27.0.0/16 -> vgw
8.8.4.4 -> vgw

8.8.4.4 is Google's secondary DNS server that's open to all and has ICMP enabled, perfect for testing.

traceroutes show no hops. The connection seems to die after going nowhere. I'm obviously missing something, but I do not know what. How can I complete this setup so all traffic shoved to the Virtual Gateway (vgw) goes over the VPN?


full gallery here, individual images below


traceroute

pings

cgw

route table details

route table entries

route table subnet associations

route table propagation

vgw details Not much useful here.

vpc details

vpn details

vpn status Only 1 tunnel is configured.

vpn static routes This is where the route table pulled the 172.27.224.0/24 address from.

  • Can you confirm that you have associated the route table with the subnet that the instance belongs in? – Victor Wong Sep 7 '18 at 2:51
  • Confirmed, verifying the vpc IDs, route table IDs, and subnet IDs. I am enabling flow logs tomorrow, so I may have more information then. – UtahJarhead Sep 7 '18 at 3:20
  • Flow logs have been added and it shows the traffic getting the ACCEPT flag, but not the location it's off to (igw, vgw, etc). I guess I was hoping for more detail from the flow logs. – UtahJarhead Sep 7 '18 at 18:33
  • I'd like to help, but your description of current state seems to be incomplete and imprecise. How about a network diagram to make things obvious? – Tim Sep 7 '18 at 18:52
1

Unless you want to create a route for every customer, change your default route to send all traffic over the VPN and remove the IGW. Then you corporate router can manage the traffic.

Your route table will then look like this:

0.0.0.0/0 -> vgw
172.31.254.0/24 -> local

The second route CIDR above looks weird - it looks like a subnet instead of a VPC network. You want this to be your VPC CIDR.

Once you have verified this this is working correctly for all traffic, then you can add a VPC endpoint to your VPC if you need to access AWS resources such as updates, S3 storage, etc.

| improve this answer | |
  • I appreciate your comment, but that's exactly what I intend on doing. We have all of their IP addresses, so scripting it is very easy. We want ONLY the connections that require our IP to use that route. – UtahJarhead Sep 16 '18 at 2:59
  • 1
    @UtahJarhead AWS VPC Route Tables have a max route entry limit of 50. You can increase this to 100 with an AWS warning about performance impact. This may impact your ability to route to 100+ customers via your strategy. docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html – John Hanley Sep 16 '18 at 16:26
  • Thank you for the heads up. We would have dealt with the performance impact. It's already a less-than-ideal situation! What's one more hiccup? – UtahJarhead Sep 16 '18 at 17:46
0

The above setup is correct. The issue has been determined to be a poor firewall on the corporate side that, when replaced, functioned just fine as a VPN endpoint. For the record, I strongly recommend AGAINST WatchGuard brand firewalls. Been screwing with them for years now and they seem to be inferior in most aspects and generally buggy.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.