Re: SNAT based on MAC before routing

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2002-11-21 at 10:08, Eduard Calvo (B-teljpa) EXP JAN 03 wrote:
>  
>   Hi Ramin, 
>  
>   Thanks for your answer. But this solution is not suitable to me. This would 
> be a good solution if the only thing I had to do is to route packets based on 
> MAC. The problem is that I have to SNAT before routing.  
>  
>   The reason is that I have to capture http traffic and redirect it through a 
> local Apache Server that I have in my Linux box. The server has to be able to 
> distinguish over hosts, and if I do SNAT in postrouting it will see the real 
> ip address of the packet, and not the NAT'ed address. I wonder if maybe Apache 
> has access to fields of the ip header (like TOS), because I would use these 
> fields to make Apache distinguish clients. 
>  

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öm of Squid proxy fame. 
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. 

However, apparently the SNAT part of the patch was quite intrusive, 
and IIRC had issues with conntrack/nat helpers. At 2.4.19-pre time, 
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 
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 
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/


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux