AWS VPN issue routing to 2nd ip block

Question

I've just setup a VPN link between our local network and an Amazon VPC.

Our local network has two ip blocks of interest:

• 192.168.0.0/16 - block local-A
• 10.1.1.0/24 - block local-B

The AWS VPC has a ip block of:

• 172.31.0.0/16 - block AWS-A

I have setup the VPN connection with static routes to the local-A and local-B ip blocks.

I can connect from:

• local-A to AWS-A and
• AWS-A to local-A.

I can't connect from:

• AWS-A to local-B (e.g. 173.31.17.135 to 10.1.1.251)

From the 173.31.17.135 server, 10.1.1.251 seems to be resolving to an Amazon server, rather than a server on our local network. This is despite setting up local-B (10.1.1.0/24) as a route on the VPN. See tracert output...

tracert 10.1.1.251

Tracing route to ip-10-1-1-251.ap-southeast-2.compute.internal [10.1.1.251]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  169.254.247.13
  2    <1 ms    <1 ms    <1 ms  169.254.247.21
  3    33 ms    35 ms    36 ms  169.254.247.22
  4    34 ms    35 ms    33 ms  ip-10-1-1-251.ap-southeast-2.compute.internal [10.1.1.251]

How can I change the config so that the 10.1.1.251 address resolves to the server on my local network when accessed from within AWS?

Disclosure - I've asked this same question at serverfault too.

Edit...tracert to the other subnet

tracert -d 192.168.0.250

Tracing route to 192.168.0.250 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  169.254.247.13
  2    <1 ms    <1 ms    <1 ms  169.254.247.21
  3    36 ms    35 ms     *     169.254.247.22
  4    35 ms    36 ms    34 ms  192.168.0.250

Edit #2...tracetcp to the bad and good destinations:

>tracetcp  10.1.1.251 -n

Tracing route to 10.1.1.251 on port 80
Over a maximum of 30 hops.
1       0 ms    0 ms    0 ms    169.254.247.13
2       0 ms    0 ms    0 ms    169.254.247.21
3       31 ms   31 ms   16 ms   169.254.247.22
4       *       *       *       Request timed out.
5       ^C

>tracetcp  192.168.0.250  -n

Tracing route to 192.168.0.250 on port 80
Over a maximum of 30 hops.
1       0 ms    0 ms    0 ms    169.254.247.13
2       0 ms    0 ms    0 ms    169.254.247.21
3       47 ms   46 ms   32 ms   169.254.247.22
4       Destination Reached in 31 ms. Connection established to 192.168.0.250
Trace Complete.

Hop #3 is the VPN end point on the local side. We are getting that far and then something is failing to route past that. So yes, the problem is on our side, i.e. AWS setup is fine. I'll update when we get to the bottom of it.

Edit #3

Fixed! The problem was the Barracuda Firewall that we run internally. We had created incoming and outgoing holes in the firewall AND there were no logs showing blocked requested to the destination so we had ruled the firewall out as the cause early on. In desperation we quickly switched the firewall off and the connection went through ok. Since then we have updated the firmware on the firewall and it has fixed the issue and the firewall is now allowing through the traffic.

tracert and tracetcp were helpful diagnostics but the firewall never showed up on the list of hops (even now it's fixed) so it was hard to tell the firewall was blocking it. I would have expected all traffic to be passing through the firewall and that the firewall would be in the hop list. Thanks for the help.

Answer 1

You appear to be blurring the distinction between routing and name resolution. These two things are completely unrelated.

Looking at the round-trip-times, it certainly doesn't look like you're hitting an AWS server. I would speculate that you're routing fine, but amazon's internal DNS service is showing you the wrong name.

Have you actually tried connecting to your 10.1.1.251 machine? Intuition tells me it's fine, you're just seeing a hostname you don't expect.

The fix, of course, is to configure your EC2 VPC instances to use your corporate DNS servers instead of Amazon's. Or you can just use tracert -d so that you don't see this. :)

---

Okay, update. Your references to resolution and the latency involved made me think otherwise. I'm still inclined to think you actually have connectivity at some level, though because the 36 milliseconds seems inexplicably high. What's the round-trip time to the other subnet?

Can you pull the Ethernet cable from 10.1.1.251 and see if it stops responding?

If you trace from a 10.1.1.x machine on your LAN toward the VPC or try to connect to a VPC machine from 10.1.1.x... what happens there?