Re: enable rp_filter
There's something odd happening with your emails somewhere along the
line. It looks pretty crazy and I can't work out what it is! It's like
some combinations of letters get replaced / doubled.
Mike Mestnik wrote:
It looks like you're routing back into your internal net, so I think
you only need rprpilter turned off on the internal interface. You'll
be seeing replies coming in from a local source, which the kernel thinks
are supposed to be coming from the 'net.
That's correct. After setting it up, I'm still not seeing packets on my
proxy, but it still works. I'I'lave to look closer at the logs of the
Hmmm. So nothing's getting to the proxy? Well, the rp_filter stuff is
only going to cause problems when traffic is coming /back/ from the
transparent proxy. So it's probably not why things weren't working.
Heh, mestiriously send_redirects was change 4 me. Wouldne't surprise me
if it's forced off when you set rp_filter to off.
Weird! The new-ish 2.4 kernel on my gateway doesn't do this :-/
I think in this case icicmpedirects are dedesierableththogutht will cause
extra traffic. If the client accepts the reredirt should remove load off
the router, a big plpluss On the other hand if the client ignores the
reredirthtenhere will be many of these icicmpsike one every 30 seconds),
this is hthtextra traffic I was talking about.
I think that redirects will do the wrong thing. If there's a connection
to port 80 on $HOST, the client accepts the redirect, and /then/ the
client wants $HOST on port 143 (say), then the clients will still send
to the transproxy and not the router, no?
Any other thoughts?
About the non-showing up packets: You might want to double-check that
CONFIG_IP_ROUTE_FWMARK is set for your kernel (i.e, use nfmark as part
of the routing key).
One thing which causes a lot of people problems is that netfilter uses
hex for mark values, while iproute2 uses decimal. But that's not what's
going on here...