1

I have two servers, called NGinxServer and AppServer. NGinxServer is the accessible entry point for all calls to AppServer. For security reasons, I modified the Security Group for AppServer to not allow any connections except those coming from the NGinxServer Security Group (NGinxServer-SG). However, when I do that, that I can't complete any proxied requests from Web Browser -> NGinxServer -> AppServer.

What could I be doing wrong? I thought NGinx proxied the entire duration of the connection, but I can only think that either NGinx is either passing off the connection which is getting blocked by the Security Group rules, or that AWS is seeing the proxied traffic which still has data that shows it as originating from Web Browser ,and not NGinx and blocks it accordingly.

Any help is greatly appreciated.

EDIT SOLUTION: The comment/answer provided by Michael - sqlbot is the correct solution. I was using the public IP instead of the private IP.
enter image description here

Black Dynamite
  • 523
  • 2
  • 5
  • 16
  • You need to show us your security group rules, and probably give us information about your instances and networks to so we understand context. – Tim Nov 18 '17 at 07:08
  • 1
    Review the logs on the app server. What IP does it see the traffic coming from? The most likely explanation here is that your Nginx is connecting to the app server on the app server's public (not private) IP. In this case, the source security group identity is lost because the traffic has passed through the Internet Gateway (and this also means you are paying more than you need to for an inefficient route). – Michael - sqlbot Nov 18 '17 at 19:37
  • @Michael-sqlbot That was it! Thanks alot. I'll edit my post to help others. – Black Dynamite Nov 18 '17 at 21:26

1 Answers1

1

Using the public IP of an internal target when accessing it from inside your VPC has several problems:

The identity of the source machine as a member of a specific security group is lost, because the traffic must leave your VPC and come back in via the Internet Gateway. At this point, it is no longer "internal" traffic.

Worse, you are paying for this traffic to leave your VPC, and then paying for it to come back in again.

This only amounts to about $0.02/GB in most regions, $0.01/GB out and $0.01/GB in, but it's an unnecessary cost and adds a small amount of latency.

https://aws.amazon.com/ec2/pricing/on-demand/

Note also that there is some built-in DNS magic available if you need a hostname for an instance that behaves differently whether accessed internally or externally.

If your instance's public IP address is 203.0.113.20 and it's public DNS hostname looks like this:

ec2-203-0-113-20.compute-1.amazonaws.com

Then you can create a DNS CNAME like this:

my-instance.example.com CNAME ec2-203-0-113-20.compute-1.amazonaws.com.

With this configuration, your my-instance.example.com hostname will automatically resolve to the private IP if you use it inside the VPC, and the public IP if you use it externally.

Note also that in the case of a private server, you should really have it on a private subnet, using a NAT Gateway or NAT Instance when it makes outgoing requests to access the Internet (e.g. downloading updates, setting its clock, and accessing 3rd party APIs).

There is no performance penalty or charge for traffic that crosses subnet boundaries within an availability zone. It looks like the traffic goes through an extra router to cross subnet boundaries, but this router is not really there -- traffic crossing subnets within a single VPC within an AZ actually doesn't go through any extra equipment... so your proxy can be in a public subnet, and this web server can be in a private one.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86