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.