Date: Wed, 4 Dec 2002 12:45:27 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Don Bowman <don@sandvine.com> Cc: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: SO_DONTROUTE, arp's, ipfw fwd, etc Message-ID: <Pine.BSF.4.21.0212041214500.26728-100000@InterJet.elischer.org> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337010230F4@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Dec 2002, Don Bowman wrote: > > From: Don Bowman [mailto:don@sandvine.com] > > I have a setup where I have a transparent proxy using ipfw fwd (to > > localhost). > > Data is sent to this device using a MAC rewrite so that > > packets arrive with > > my MAC, but the original source and destination IP. > > When I receive the SYN, i accept the connection, which causes an ARP > > to be emitted for the source address, and then the SYN/ACK. > > I didn't get much response from this, so I'm going to re-phrase. > > Is there any reason that I shouldn't modify the TCP passive accept > so that it remembers both the MAC address of the sender, and the > interface the packet came in on? By doing so, I will avoid > having to issue an ARP for each incoming connection (which adds > latency, and more importantly for me, breaks the ability to use > ipfw 'fwd' rules the way I want). [This is with FreeBSD 4.7 if > it matters]. > The arp is issued because the TCP stack is responding to the SYN packet with it's own SYN, but it doesn't have a route to the origianal source, so it creates one, as it's local. this means that it allocates an ARP entry for it which in turn causes an arp request to be sent. The response will result in the SYN being transmitted. This is all pretty normal. there will not be another ARP sent for 18 minutes for that host.. thw question is.. Why does it think the source is local? are the routers below doing proxy arp? Did you give your interface a netmask of 0,0.0.0? Who responds to the arp? > What's happening is I have >1 router feeding me sessions which > I'm transparently proxying (e.g. squid). > Obviously I can't have a default route back to each of them. > > So I have something like: > > [Router1]---\ > \ > [Router2]--------[BSD] > / > [Router3]---/ > > This is done with a layer-2 mac rewrite, ie the router takes the packet, > doesn't modify the IP header, but changes the destination MAC to > be that of the BSD machine. yes the ipfw fwd command does the same thing if you were using a freeBSD box as such a router. (it sends the packet on with a different MAC header) (if you were not using localhost as the destination of the fwd. > > So, e.g, a packet comes into router1 above (from somewhere on its > left hand side). It may have IPsrc=1.0.0.1, IPdst=2.0.0.1. > It then arrives @ the BSD machine, which will cheerfully say, yup, > I'm 2.0.0.1 (using the beauty of 'ipfw fwd localhost...'). > Problem is, it then wants to send a SYN/ACK, there's no route, > so no where to go. I can't make the route be one of those routers, > and the routing tables are too complicated to install (since there > may be BGP on the left of them, etc, etc). Its important for > me the response packets go back through the same path (to avoid > reordering etc). if there is bgp to the left, you could make this machine take part.. do the routers do bgp? You COULD write a netgraph node that adds routes as it receives packets in fact it could keep it's own cache of IP/MAC mappings and switch the MACs appropriatly on outgoing packets. Possibly adding routes would be best. It would identify the source from the src mac address, and add add the appropriate entry to the routing table. a bit like a learning bridge. > > The next step for me is to use a separate VLAN from each of those > routers to the BSD box (so that the packets appear to come from different > interfaces). I'd like to memorize the interface the packet came in, > and the mac header to use, and just use that without making an enormous > arp table, and going back to the place the SYN came from. You could use divert sockets for this.. as the packets arrive they are diverted up.. part of the info a divert socket provides is the receiving interface. A divert daemon cound examine the packet and add teh appropriate route into the routing table, depending on the incoming interface. (just ideas). > > Is there a reason it doesn't work this way currently (before I dive > in and make changes). I'm not sure what you mean.. Is there a reason that return routes are not added every time a packet is received? Well, yes. For a start it may not be what everyone wants. I have made great use of asymetrical routing many times (e.g. some satelite internet connections are via modem for outgoing and via the satelite for incoming.) > If I were to change it to work the way I want, would other people > be interested? > Would this be interesting as a whole-sale change in behaviour, or as > a sysctl-changeable or #ifdef settable? I think you could do what you want without modifying the current system. Either by packet rewriting using a netgraph module, or by adaptively modifying the routing tables, either from the kernel, or from userland. > > Comments greatly appreciated. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0212041214500.26728-100000>