From mboxrd@z Thu Jan 1 00:00:00 1970 From: Filip Sneppe Date: Sun, 24 Nov 2002 00:40:30 +0000 Subject: Re: [LARTC] SNAT based on MAC before routing Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org On Thu, 2002-11-21 at 10:08, Eduard Calvo (B-teljpa) EXP JAN 03 wrote: > =20 > Hi Ramin,=20 > =20 > Thanks for your answer. But this solution is not suitable to me. This w= ould=20 > be a good solution if the only thing I had to do is to route packets base= d on=20 > MAC. The problem is that I have to SNAT before routing. =20 > =20 > The reason is that I have to capture http traffic and redirect it throu= gh a=20 > local Apache Server that I have in my Linux box. The server has to be abl= e to=20 > distinguish over hosts, and if I do SNAT in postrouting it will see the r= eal=20 > ip address of the packet, and not the NAT'ed address. I wonder if maybe A= pache=20 > has access to fields of the ip header (like TOS), because I would use the= se=20 > fields to make Apache distinguish clients.=20 > =20 Hi Eduard, You will never get SNAT in PREROUTING in iptables/netfilter, because it would seriously mess up filtering and connection tracking :-) However, you should talk to Henrik Nordstr=F6m of Squid proxy fame.=20 Here is his homepage with contact email address on it: http://devel.squid-cache.org/hno/ Here's the reason: for a very long time in the 2.4 series, it was impossible to do DNAT in the OUPUT chain (was a TODO item for the netfilter developers). Henrik had a patch he wrote that allowed DNAT in the OUTPUT chain and SNAT in the INPUT chain. This would allow you to solve your problem.=20 However, apparently the SNAT part of the patch was quite intrusive,=20 and IIRC had issues with conntrack/nat helpers. At 2.4.19-pre time,=20 the "DNAT in OUTPUT" part of the patch was aacepted by the netfilter coreteam and merged, but the "SNAT in INPUT" part of the patch got rejected. There was some discussion, and part of why it didn't get merged was that there weren't enough real-world scenario's people could come up with to convince the coreteam to accept this (the intrusiveness of the patch probably being another major=20 reason :-)). I guess Henrik, being a Squid lead developer, could see the usefulness of this patch at the time. I think an obsolete version of the patch=20 is still in the netfilter patch-o-matic. It will almost certainly not apply to 2.4.20-pre/rc/final because of the newnat merge. Henrik's a very nice and helpful guy, so you may try emailing him about your problem - he may offer some help or additional insight. It would be nice to subscribe to the netfilter-devel list for your problem and include the netfilter developers in the mailloop. The information I am presenting you is many months old so there may be stuff I am missing and people may have new insights into the problem... Regards, Filip _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/