0

I have an issue with routing.

I have 2 public subnets: 172.31.1.0/24 and 172.31.100.0/24

In each of these I have a NAT instance. Each NAT instance is an OpenSwan VPN peer to a remote location. This allows the following VPN connectivity:

172.31.1.0/24 -> 192.168.1.0/24
172.31.100.0/24 -> 192.168.100.0/24

I set up a single Route Table that is associated with both of my public subnets. this includes route entries as follows:

192.168.1.0/24 Target = NAT instance 1
192.168.100.0/24 Target = NAT instance 2

Everything works fine for the former, but no matter what I do, the route table entry for the later does not work.

No route that I setup for NAT Instance 2 works. When I traceroute to any address in 192.168.100.0/24, packets are sent directly to 192.168.100.0/24 (and therefore fail) rather than routing via NAT Instance 2.

I thought maybe there was a limit on the number of concurrent NAT instances in a Route Table, but even when I delete the route to 192.168.1.0, so that the only route that exists is the route via NAT instance 2, it still doesn't work.

I've checked all the usual stuff (Src/Dst check etc) but nothing seems to be out of place. All of this was created with CloudFormation, so manual error isn't likely.

1 Answer 1

0

The solution to this was quite straightforward, but it throws up an interesting observation re. the use of traceroute to debug routing problems.

The source of the problem was that I had not enabled ip forwarding on any host other than Nat Instance 1.

ie

echo 1 > /proc/sys/net/ipv4/ip_forward

When I had been debugging, I had been using the traceroute command eg

traceroute 192.168.100.1

When ip forwarding was not enabled on Nat Instance 2, this was producing the following response:

[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets 

When I enabled ip forwarding on Nat Instance 2, the response changed:

[server1]$ traceroute 192.168.100.1
traceroute to 192.168.100.1 (192.168.100.1), 30 hops max, 60 byte packets
1  ip-172-31-100-102.ap-southeast-1.compute.internal (172.31.100.102)  0.528 ms  0.505 ms  0.491 ms 

(172.31.100.102 = Nat Instance 2)

This suggests that while traceroute may be aware of a specific route to a specific network, it will only report an attempt to follow that route if routing is allowed on the default gateway for that route.

If not, it will attempt to follow the default route and report success or failure for the default route only. I'm sure this is consistent with the design of traceroute, but probably signals that traceroute may not be the best tool to debug routing issues (its more a tool to debug network issues).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .