0

I have a VPC with two EC2 instances:

  1. API
    • Private IP 10.0.103.200 (private subnet)
  2. VPN router
    • Private IP 10.0.103.100 (private subnet)
    • Private IP 10.0.4.100 (public subnet) and public IP
    • Internally set IP 10.69.69.1

VPN's public IP is used by external devices to connect using IPSEC/L2TP. The clients connecting this way are getting addresses from 10.69.69.0/24 space, which is managed only within the VPN machine itself. VPN machine has address 10.69.69.1

Of course, AWS routing table does not know about 10.69.69.1, however, as API can see and communicate with VPN, I should be able to just do:

ip route add 10.69.69.0/24 via 10.0.103.100

Unfortunately, this does not work and 10.69.69.1 is still not accessible from API. I have verified that VPN does not get any traffic at all in this case.

Is AWS doing something that would not let me achieve this?

End goal is to make the whole 10.69.69.0/24 accessible from API, but first step is to have access to VPN's own address in that space.

I know AWS has its own VPN services as well, but those are way too expensive for my use case. I need a bunch of boxes (LTE router, Raspbery Pi and IP camera) to be connected. AWS IoT seems cool but unfortunately probably does not solve my goal. Also, I would like to avoid having to connect from API to VPN using IPSEC/L2TP, but currently it seems to be the only option that I know of.

Improve this question
2
  • 'Of course, AWS routing table does not know about 10.69.69.1" Note that after you disable the source/dest check as noted below, you can add this subnet to the VPC route tables, specifying the VPN server's instance-id as the target. Instance route table modification is unnecessary (and shouldn't be expected to work).
    – Michael - sqlbot
    Aug 22, 2018 at 9:49
  • 1
    That is a really good tip, makes the whole thing a bit nicer. Thanks!
    – priiiiit
    Aug 22, 2018 at 9:55

1 Answer 1

Reset to default
1

Most likely you are bumping against the source/dest check that EC2 instances perform by default: they block any traffic that is not intended for their interfaces directly. This is the same issue you have when creating a NAT instance.

This can be deactivated in the console in the network settings for your instance.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .