AWS - Accessing instances in private subnet using EIP

Question

I want to access a few instances in my private subnet using EIPs. Is there a way? I know it doesn't make much sense. But let me explain in detail.

I have a VPC with 2 subnets.

1) 192.168.0.0/24 (public subnet) has EIPs attached to it

2) 192.168.1.0/24 (private subnet)

There is a NAT instance between these to allow the private instances have outbound access to the internet. Everything works fine as mentioned here : http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html

But now, for a temporary time I need to address the instances on the private subnet directly from the internet using a EIP. Is this possible by setting up new route tables for that particular instance alone? or anything else? Here are the limitations :

1) There can't be any downtime on any instances on the private subnet

2) Hence it goes without saying, I can't create a new subnet and move these instances there.

It should be as simple as -> Attach. Use . Remove. The only other way I have right now is some kind of port fowarding on iptables from instances on the public subnet (which have EIP) to any instance on private subnet... But this looks messy .

Any other way to do it ?

Answer 1

Of course, the stuff in the private subnet is in the private subnet because it shouldn't be accessible from the Internet. :)

But... I'm sure you have you reasons, so here goes:

First, no, you can't do this in a straightforward attach → use → remove way, because each subnet has exactly one default route, and that either points to the igw object (public subnet) or the NAT instance (private subnet). If you bind an elastic IP to a machine in the private subnet, the inbound traffic would arrive at the instance, but the outbound reply traffic would be routed back through the NAT instance, which would either discard or mangle it, since you can't route asymmetrically through NAT, and that's what would happen here.

If your services are TCP services (http, remote desktop, yadda yadda) then here's a piece of short term hackery that would work very nicely and avoid the hassles of iptables and expose only the specific service you need:

Fire up a new micro instance with ubuntu 12.04 LTS in the public subnet, with an EIP and appropriate security group to allow the inbound Internet traffic to the desired ports. Allow yourself ssh access to the new instance. Allow access from that machine to the inside machine. Then:

$ sudo apt-get update
$ sudo apt-get upgrade 
$ sudo apt-get install redir

Assuming you want to send incoming port 80 traffic to port 80 on a private instance:

$ sudo redir --lport=80 --cport=80 --caddr=[private instance ip] --syslog &

Done. You'll have a log of every connect and disconnect with port numbers and bytes transferred in your syslogs. The disadvantage is that if your private host is looking at the IP of the connecting machine it will always see the internal IP of the private network instance.

You only have to run it with sudo if you're binding to a port below 1024 since only root can bind to the lower port numbers. To stop it, find the pid and kill it, or sudo killall redir.

The spiffy little redir utility does its magic in user space, making it simpler (imho) than iptables. It sets up a listen socket on the designated --lport port. For each inbound connection, it forks itself, establishes an outbound connection to the --caddr on --cport and ties the two data streams together. It has no awareness of what's going on inside the stream, so it should work for just about anything TCP. This also means you should be able to pass quite a lot of traffic through, in spite of using a Micro.

When you're done, throw away the micro instance and your network is back to normal.

Answer 2

Depending on your requirements, you could end up putting in a static route direct to the igw.

For example, if you know your source on the internet from which you want to allow traffic, you can put in the route x.x.x.x/32 -> igw into your private routing table. Because your instance has a EIP attached it will be able to reach the igw, and traffic out to that destination will go where it should and not the NAT.

I have used this trick a few times for short term access. Obviously this is a short term workaround and not suitable for prod environments, and only works if you know where your internet traffic is coming from.

Answer 3

I suggest you setup a VPN server. This script creates a VPN server without having to do much work: https://github.com/viljoviitanen/setup-simple-openvpn

Just stop and start as required.

Answer 4

1-use of redir utility from a temporary EC2 instance to the NAT private subnet. For this option consider that is the least intrusive. Is possible to make it persistent by creating a system service so in case of reboot the socket will be created again. 2-static routing table this requires medium to advanced knowledge on the AWS VPC and depending on the case you might need to deal with AWS Route 53 3-VPN: It could mean dealing with the Amazon IGW plus some extra steps.

The best solution for me was 1 plus different port mapping, creating a DNS record in AWS 53, security groups restrictions. The requirement is the opposite: to leave the connection constant for certain users to access on daily basis and at some point being able to stop the EC2 instance.