[lug] AWS VPC question for VPN

Bear Giles bgiles at coyotesong.com
Sun Jul 16 08:32:46 MDT 2017


Quick question on networking permissions on AWS VPC for a VPN.

I only allow inbound access from two sites:

1. UDP 1194 from anywhere
2. TCP 22 from my jump host within AWS. It's not accessible from anywhere
on the internet at large.

(modulo AWS properly setting up their switches, etc.)

I can connect to the site via SSH and can successfully establish a
connection to VPN from home home system. However everything times out on
the VPN. When I check on the VPN server I can't 'dial out'. I can see AWS
internal resources, e.g., the ubuntu repository, but not the world at
large. (but see below)

I know that VPCs require gateways (which I have set up - I think) and NATs
(for systems that don't have any public IP addresses, e.g., the postgresql
server I'm trying to set up as well) but don't think that applies here.

The outbound routes allow TCP anywhere.

(It's not an issue with DNS being blocked - the server resolves the IP
addresses of the test sites I'm trying to reach.)

The only possible issue that I can think of is that I have a parent VPC -
10.x.0.0/16, and am creating subnets for individual classes of servers.
10.x.a.0/24 has the jump server, 10.x.b.0/24 has the VPN server,
10.x.c.0/24 has the database server, etc. That way I can create a security
policy that refers to a subnet as a whole and I don't have to change the
details if I bring in a new server in the same class. However some things,
e.g., the internet gateway and egress-only internet gateway, refer to the
parent VPC - 10.x.0.0/16 - and there's no way to specify a subnet. I don't
know if that's a problem, e.g., maybe I need to add an additional service.

(below)

There's one exception to "sees the AWS ubuntu repository". The database
server, which has no public IP address, doesn't see it. I tried adding the
ubuntu repository servers to the whitelist or even adding a NAT but no joy.

This is half-exciting and half-annoying since I'm trying to verify some
'best practices' in the real world. One is that the database server be on
an internal-network only system, the second is that it only allows incoming
connection on the database port and ssh and those should arguably be on
different network devices, and third that it only allows outbound
connections to the web server that needs it. Plus a handful of other
locations as needed for operation, e.g., you would definitely want NTP.
You'll want DNS and apt-get (or yum) access but it could be restricted to
maintenance windows. And that's it - every other port, both in- and
out-bound, should be blocked.

However you do need to be able to establish the latter outbound connections.

There's a partial workaround - one that would be recommended at the
enterprise level. Run your own DNS server and Ubuntu (or RedHat/Fedora)
repository. The former allows you to vet the packages that will be
available and the latter allows you to set the DNS server to 'do not
propagate' so nobody can perform data extraction via DNS payloads or
redirect you to compromised sites. It sounds good but just kicks the can
down the road since you can make a strong argument that the internal-only
systems should talk to an internal-only repository and DNS servers. Those
servers, in turn, will talk to servers that are connected to the internet
at large. That gives you a level of protection against DDOS against the
internal resources since they'll continue to function even if the
public-facing ones have to be taken down.

Bear
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20170716/23414495/attachment.html>


More information about the LUG mailing list