I have a VPC using the network 10.10.0.0/16, and a VPN server in the public subnet (10.10.0.0/24). The VPN uses addresses in the 10.11.254.0/24 range. When I connect to the VPN, I can access hosts in both the public subnet and the private subnet (10.10.1.0/24), so I believe I have the routing table set up properly to send packets bound for the VPN back through the VPN server. I have disabled source/destination checks on the VPN server (which is also needed to be able to access other hosts in the network).
The AmazonProvidedDNS server seems to be working properly inside the VPC; I can run dig @10.10.0.2 ip-10-10-1-215.ec2.internal from a host in the VPC, and I get the expected response.
However, if I run that same dig command from may laptop, connected to the VPN, I get no response.
From running tcpdump on the vpn server, I see the A? packets coming from my VPN address, going to 10.10.0.2, but I don't see any response coming back. Is there something I need to do to enable the DNS server to answer requests from outside the VPC address range?
Best Answer
That sounds like unusual way to do it, but given the inside/outside split resolution magic they've implemented, I can see why it makes sense (now that I think about it).
It's unlikely that the EC2 DNS resolvers would answer requests from a foreign IP address, but there should be an easy workaround.
For example, if your IP address on the vpn is 192.168.2.*, then, on the vpn server in VPC...
This adds a rule to the network address translation table so that after it makes the routing decision on packets from the specified source block to the specified destination block, instead of just forwarding the packet as usual, it will strip off your IP and add its own IP as the source address, and it will memorize the request. When the response comes back, addressed to the vpn server's IP, it will again rewrite the address (destination, this time, back to your address) and send the response back to you.
That should accomplish what you want.