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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
