6

This is perhaps a weird question, but I'm in a weird situation where I want to route traffic from network A 192.168.1.0/24 to network B 192.168.2.0/24 via 192.168.1.5 (the address of B-router in the A network). The A-router doesn't have a configuration interface, I can't touch it. But I can do anything with B-router.

So I was thinking perhaps I could achieve "artificial" routing by inserting the addresses allocated within the B network into A-router's ARP table, pointing to B-router's mac-address.
It should be enough for B-router to periodically send out ARP broadcasts on the A network for each of it's entries in the B network (all pointing to it's own A-network mac address).
A-router's ARP table would then look something like:

192.168.1.3 -> [some device on A network]
192.168.1.4 -> [another device on A network]
192.168.1.5 -> [B's address on A network]
192.168.2.2 -> [B's address on A network]
192.168.2.3 -> [B's address on A network]
192.168.2.4 -> [B's address on A network]
192.168.1.6 -> [another device on A network]

My belief is if A-router allows these entries in it's ARP table, then the lower-level switch logic within that router should direct the packets to B-router's interface. Before they go up the chain in A-router and it finds out it doesn't know what to do with them.

I realize this is incredibly hacky, but this is a one-off situation where I'm unfortunately left with no other choice.

So could this work, or is there any reason it wouldn't?

TrisT
  • 163
  • 5

3 Answers3

6

"It doesn't work like that."

Nothing in network A will even attempt to find network B via layer-2 (ARP), because it's not a local ("on-link") network. They will forward that traffic according to their route table -- without a more specific route (192.168.2.0/24 via 192.168.1.5) the default route applies. You could attempt to "poison" the arp tables, but (a) they won't be consulted, and (b) any sane host will ignore such martians.

Your options are:

  • add a route to the router for network A (which you said is not available to you)
  • add a route on every node in network A
  • send an ICMP redirect for network B hosts (but modern security is to ignore redirects)
Ricky
  • 32,810
  • 2
  • 45
  • 85
5

You seem to be talking about proxy ARP: the source (or previous hop) thinks that an address is on link (this might be a problem for you). On-link addresses are resolved by ARP, so an ARP request is sent.

When the gateway/router to that address then replies with its own MAC address, the source sends the packet to that MAC address, just like it would using its routing table to find a gateway. On the gateway, the packet is routed by its IP address, so all is working well.

However, proxy ARP is a bad crutch and should be avoided. The reasonable method would be to replace A-router with a more capable model. Alternatively, add a route to 192.168.2.0/24 via 192.168.1.5 to each node in 192.168.1.0/24.

It should be enough for B-router to periodically send out ARP broadcasts on the A network for each of it's entries in the B network

I'm afraid gratuitous ARP is only half the solution. A-router needs to think that it's directly connected to the B-network in order to attempt ARP resolution. You'll likely need to manipulate its network mask, assuming A-network and B-network can be supernetted. In your example, you'd need to shorten the network prefix from /24 to /22.

Can ARP tables store addresses for other networks?

That would be useless. MAC addresses are only meaningful within the network segment that they are connected to. As described above, it may be useful though to insert a gateway's MAC address for an IP address that looks like it's connected to the current subnet but isn't really.

Zac67
  • 90,111
  • 4
  • 75
  • 141
0

I'm not 100% sure if it works, but as @Ricky says, you could add separate routes for each network element in network A.

For Linux it works like this:

Put custom static routes in /etc/network/interfaces:

auto eth0
iface eth0 inet static
      address 192.168.1.XX
      netmask 255.255.255.0
      up route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.1.5

where eth0 is of course the network interface, that's connected to your LAN A and XX is the IP of your Linux network element in LAN A. The Link will give you further Information.

You can get your current routes using: route -n

For Windows it works like this:

route -p add destination_network MASK subnet_mask gateway_ip metric_cost
route -p add 192.168.2.0 MASK 255.255.255.0 192.168.1.5 0

Don't forget the -p flag, as it makes the route persistent. You can get your current routes with route print

While this is certainly not the most elegant solution, it could be an acceptable workaround if you have absolutely no access to Router A and other tinkering might not want to work either.

JJandke
  • 1
  • 1