From owner-freebsd-net@FreeBSD.ORG Thu Feb 18 02:34:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 564C91065672 for ; Thu, 18 Feb 2010 02:34:22 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from smtp.ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id B88978FC13 for ; Thu, 18 Feb 2010 02:34:21 +0000 (UTC) Received: (qmail 50377 invoked by uid 89); 18 Feb 2010 02:38:10 -0000 Received: from unknown (HELO ?192.168.1.114?) (steve@ibctech.ca@::ffff:208.70.104.100) by ::ffff:208.70.104.210 with ESMTPA; 18 Feb 2010 02:38:10 -0000 Message-ID: <4B7CA72A.4050202@ibctech.ca> Date: Wed, 17 Feb 2010 21:34:18 -0500 From: Steve Bertrand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christian Ullrich References: <4B7C62AF.6000904@chrullrich.net> In-Reply-To: <4B7C62AF.6000904@chrullrich.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Routing into overlapping subnets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 02:34:22 -0000 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