Routing into overlapping subnets

[Steve Bertrand]

On 2010.02.17 16:42, Christian Ullrich wrote:
> Hello all,
> 
> I'm having a routing problem I can't wrap my head around. Consider this
> situation: I want to provide some common resources (printers etc.) to a
> number of clients in separate networks. They each have their own
> physical network, and these networks are supposed to stay isolated, with
> the exception of what I'm trying to set up. I have no control over the
> IP addressing used by the clients, except that it's all RFC1918, but as
> far as I know, they are all using the same addresses.
> 
> What I thought would work was this: On a central switch, set up one VLAN
> per client network and ensure that the switch only forwards between the
> port assigned to the client and one (trunk) port where I put my router.
> On the router, create the required VLAN interfaces and put the "public"
> addresses for my printers on them (one in each RFC1918 net, but the same
> on each VLAN), then use pf to NAT the destination for packets coming in
> on each VLAN to the actual printers, and use "reply-to" to make sure the
> responses go out through the same interface.
> 
> Now I'm stuck. With one client, that works fine, but when I add another
> one (different interface, same client address), the packets are dropped
> and dmesg shows lots of "arpresolve: can't allocate llinfo for (client
> address)". I suppose that's because there is already an ARP entry for
> that IP address, and the kernel cannot add another one.
> 
> If that's true, here's what I don't understand: When the time comes to
> resolve IP addresses to hardware addresses, the kernel has already
> routed the packet to an outgoing interface, so it should be enough to
> consider the ARP entries associated with that interface to know where to
> send the packet. Why doesn't the kernel look up an ARP table entry by
> both IP address and interface?

That's not how the protocols were designed, and thankfully so. Imagine
the potential for spoofing if this were allowed by default ;)

> Is there anything I can do to make this work? It's not an everyday
> setup, I know, but I'd really like to make it work.

I have a couple of ideas, but need to understand better of your setup.
Advise if this seems semi-accurate:

- you house global resources for a bunch of clients at a central location
- you have limited public IP addresses to do this with, or your central
location is located within the same 'building' as all of the clients
- you have several clients with overlapping 1918 space
- you need a method to have two instances of eg 192.168.1.110 accessing
a single central resource, but which will be coming in on two separate
interfaces (physical or virtual)
- the central services (ie printer) doesn't have the capability to house
more than a single IPv4 address
- you do not want to be open to the potential for one client accessing
the others networks
- you have absolute control over the pf box

is this right?

Steve