0

I have the following topology:

+--------------------------------------------------+
|                Segment 192.168/24                |
|                                                  |
|       Machine A               Network Router R   |
|  +-----------------+        +-----------------+  |
|  |  192.168.0.110  |        |  192.168.0.1    |  |
|  |                 |        |                 |  |
|  +-----------------+        +-----------------+  |
|           +-------------------------+            |
|           |        Machine B        |            |
|           |   +-----------------+   |            |
|           |   |  192.168.0.112  |   |            |
|           |   |  172.20.1.1     |   |            |
|           |   +-----------------+   |            |
+--------------------------------------------------+
            |        Machine C        |
            |   +-----------------+   |
            |   |                 |   |
            |   |  172.20.1.100   |   |
            |   +-----------------+   |
            |                         |
            |    Segment 172.20/16    |
            +-------------------------+

Segment 192.168/24 is a physical LAN, segment 172.20/16 is a VPN. I want to use machine B as a router between both segments. B is a Linux machine with IP forwarding and NAT enabled.

When I create a route in machine A to the 172.20/16 network (through 192.168.0.112), I can reach machine C correctly.

When, however, I create a route in the 192.168/24 segment's default gateway (the network router R) to 172.20/16 through 192.168.0.112, the following is true with regards to attempt reaching machine C:

  • Pings originated from the router itself (192.168.0.1) receive replies correctly;
  • Pings originated from A go to R, then go to B, but are not forwarded to C;
  • No ICMP redirects are generated.

I've made packet captures in every node, and:

  1. When the aforementioned route is in A, the ethernet destination address of the frames that reach B is set to the MAC of B (that is, A sends to B directly);
  2. When the aforementioned route in in R, the ethernet destination address of the frames that reach B is set to the MAC of R (that is, A sends to R, R "sends" to B but eth.dst is the original MAC from A to R).

This is the only difference between the setups. Apparently B is discarding the frames that have the wrong MAC address.

The interesting part is that I have exactly the same setup working in another infrastructure (mostly different hardware).

What can I do in order to fix this setup?

alecov
  • 552
  • 1
  • 6
  • 13

1 Answers1

1

You should be getting ICMP redirect message instead of ICMP echo reply you expected.

The host 192.168.0.110 sends ICMP echo request to its default gateway 192.168.0.1 which then should redirect the packet to 192.168.0.112 to reach subnet 172.20.0.0/16. The gateway in this case will respond with ICMP Redirect (as it is shorter to send the ping message directly to 192.168.0.112).

Here is a related serverfault post.

To fix this issue on a Linux machine, I add a static route on the sending machine 192.168.0.110 like:

$ sudo route add -net 172.20.0.0/16 gw 192.168.0.112

When this static route is added, this machine will not contact the default gateway when trying to reach 172.20.0.0/16 subnet.

Community
  • 1
Khaled
  • 35,688
  • 8
  • 69
  • 98
  • In that case, I wouldn't be able to actually _see_ the ping reaching 192.168.0.112, as I currently am, would I? Also, no TCP server in 172.20.1.100 is reachable: I see the connection requests (`SYN` packets) reaching 192.168.0.112, but they don't get forwarded to `tap0`, exactly as in the ping scenario. – alecov Oct 03 '16 at 15:02
  • I've rewritten the question in hope to make the situation clearer. – alecov Oct 06 '16 at 20:38