0

Network diagram

Consider the following network ^^^.

The virtual network setup in Azure: 10.10.0.0/16 with 1 subnet, 10.10.0.0/16 and a gateway subnet at 10.10.1.0/29.

Azure knows how our network looks like, 2 address spaces: 192.168.101.0/24 & 10.246.0.0/16 via an additional router.

I would like to achieve bydirectional communication from & to Azure.

At the moment we set it up with a machine on-premise (with IP 192.168.101.36) which runs Windows Server 2012 R2 with RRAS. It dials in to Azure, and we have connection.

The first route on RRAS is 10.10.0.0/16. This ensures that any machine in the local network (192.168.101.0/24) can reach the Azure network. The second route is 192.168.101.0/24, this is to ensure that Azure can talk to us. Question: What should be the gateway here: 192.168.101.1 (the DHCP server) or 192.168.101.36 (the RRAS server)

The third route ensures that any traffic that comes in to the RRAS server that wants to talk to the 10.246.0.0/16 network is forwarded to 192.168.101.10, which is the 3G modem/router.

Now we're missing a piece, but let me first explain what works:

  • A machine in Azure can ping anything in the 192.168.101.0/24
  • A machine in our on premise network (192.168.101.0/24) can ping anything in Azure (10.10.0.0/24).
  • A machine in our on premise network (192.168.101.0/24) can ping anything behind the 3G modem (10.246.0.0/24).

BUT (and this is my next, and most important question) no machine in Azure can ping the 3G network UNLESS I add a static route on the 3G modem/router that says: 10.10.0.0/16 to gateway 192.168.101.36.

How come the 3G modem/router doesn't know how to redirect the traffic back to 192.168.101.36, after all it has that particular IP as Gateway.

Is it because 10.*.*.* and 192.168.*.* are not routable?

Update: went to look in the 3G router/modem and found this:

#> display route

 Route Table:

 Destination         Gw              Refs Mhome Iface    mtu  hops ttl         flags
 0.0.0.0/0           10.246.52.3     1    0     mobile0  1500 1    INF         UGS
 10.10.0.0/16        192.168.101.36  2    0     eth0     1500 1    INF         UGS
 10.246.52.0/29      *               1    0     mobile0  1500 0    INF         UC
 127.0.0.0/8         127.0.0.1       1    0     LOOPBACK 1500 1    INF         UGJS
 127.0.0.1/32        127.0.0.1       6    0     LOOPBACK 1500 0    INF         UH
 192.168.101.0/24    *               1    0     eth0     1500 0    INF         UC

It seems that the first one 'eats' all network, and the second one (that is the static route I've added) fixes that. And the last one is because he knows he's on the 192.168.101.0/24 network. It is weird though that there's no gateway address there.

Anemoia
  • 306
  • 1
  • 5
  • 15

1 Answers1

1

I'd be surprised if you need a static route on the RRAS server for 192.168.101.0/24 at all, as it is a "directly connected" network - the RRAS server should know how to get to that network without a static route configured. In any event, setting the gateway for 192.168.101.0/24 as the RRAS server's IP on that network is functional, as you have discovered (this is effectively what connecting an interface to a subnet does by default), but will break if the RRAS IP changes on that network, so it's probably easier to remove the static route.

Without a configured route, the 3G router has no knowledge of the 10.10.0.0/16 subnet as it is not a directly connected interface, so will, without any further instruction, send traffic to that subnet over it's default gateway (most likely, directly to the internet). If it doesn't have a default gateway, the traffic will simply go nowhere.

The static route is required on the 3G router to tell it that traffic for 10.10.0.0/16 has to be directed to the RRAS server on 192.168.1.36 as that is the correct gateway for that subnet.

The reason azure machines can't ping machines in 10.246.0.0/24 without that route is because although the azure machines can get to the 10.246.0.0/24 subnet (there are correctly configured routes in that direction) the replies from those pings can't get back without the routes in the reverse direction being configured properly.

Let's take an example of an icmp echo request between two IPs:
10.10.1.20 sends an echo to 10.246.10.10.
The Azure setup knows that the RRAS is the gateway for 10.246.0.0/16
The RRAS knows that the 3G router is the gateway for 10.246.0.0/16
The 3g router sends the packet onto the 10.246.0.0/16 network for 10.246.10.10
10.246.10.10 receives and generates a reply
10.246.10.10 has a default gateway of the 3g router, so it sends it to the 3g router
the 3g router has no path to 10.10.0.0/16, and drops the packet or sends it to the default gateway of last resort (which is clearly not the RRAS server, or another route is overriding the default gateway) - the packet is lost

Phil
  • 1,222
  • 1
  • 7
  • 15
  • Thanks for the answer Phil, The first route needs to be there because otherwise the VPN in Azure doesn't send the traffic to me. That's how it works apparently. The thing is, the 3G modem has the `.36` as standard gateway. That's what bothers me. Or does he think that `10.10.0.0/16` belongs to the other side of the router (i.e. the 3G network itself?) – Anemoia May 09 '15 at 14:34
  • The first route, or the second route? I was talking about the "second route" eg the static route on the RRAS that points 192.168.101.0/24 to the gateway 192.168.101.36. This routing information should be known (unless RRAS has it's own routing table that we're talking about?) – Phil May 09 '15 at 14:35
  • If the 3g router has 192.168.101.36 as it's default gateway, there must be a more specific (more specific than 0.0.0.0, I mean) route on there that is causing traffic for 10.10.0.0/16 to be sent elsewhere in the absence of a specific static route. Many 3G networks issue WAN IPs in the 10 range and use carrier grade nat, so it could be related to that. – Phil May 09 '15 at 14:37
  • the route I mentioned the `192.168.101.0/24` is required for Azure -> local connections. For your second comment: Then that must be it. Thanks! – Anemoia May 09 '15 at 14:40