On Wed, 23 Jan 2002 kuznet@xxxxxxxxxxxxx wrote:
> > rules :) If the netfilter gurus don't find it useful, no problem :)
> Well, this is right. I join their opinion too. :-)
OK :) I still don't have their :)
> > Of course, the SNAT-ing process may be needs correct routing (may be
> > a new "ROUTING" chain) and little routing code changes (I have it in some
> > my patches).
> BTW this is puzzle for me: how do they block redirects?
You mean the ICMP redirects? IIRC, they catch them in
postrouting and drop them (icmp_reply_translation).
> This was another big problem with masquerading in 2.2 and in fact another
> advantage of controlling masquearding via routing, when all such things
> went right automatically.
The problem (even in 2.2) is for setup with multiple default
gateways with distinct IP ranges. Once the the connections are bound
to maddr we can't change it. But if a routing cache entry expires or
someone flushes the cache the multipath routes forget the right
directions that was used from this maddr to the universe. So, I
use the trick to do proper routing from maddr to universe at
routing time. By this way the multipath route is hit only for
the first masqueraded packet from each connection, once bound to
maddr we don't hit it. In Netfilter I do such trick by hooking at
the end of prerouting (we don't have a routing chain) and calling
modified ip_route_input with one additional argument named "lsrc":
I load it with maddr because we know what source address
manipulation is scheduled for postrouting. As result, the modified
ip_route_input behaves also as ip_route_output, it is a mixed
version (lsrc must be local IP, same check as in ip_route_output)...
I stop the ICMP redirects, just like for the RTCF_?NAT/MASQ case.
I can point you to the right place if you prefer:
I use function net/ipv4/netfilter/ip_nat_core.c:ip_nat_route_input()
that calls ip_route_input, changed in route.c. I add one arg for
ip_route_output (gw) but this is different issue. The result is
always one ip_route_input but smarter one.
This is the reason I'm talking about ROUTING hook,
the SNAT-ed traffic can be routed properly when using multipath
routes. rtmasq is not immune to this problem. The best approach
for rtmasq is to call fib_lookup by using the srcmap/prefsrc
as source. The value 0 in srcmap always causes the masquerading
(in 2.2) to call ip_route_output, the same is in my patch for 2.4,
one extra call for each connection isntead of one call for each
slow route lookup. But the problem with the missing lsrc functionality
remains: we can misroute the masqueraded traffic.
> So, it is not so bad idea to install some filter dropping panic emails
> to /dev/null before an attempt to sanitize this. :-)
Yes, the compatibility ...
Julian Anastasov <ja@xxxxxx>