Thread (1 message) 1 message, 1 author, 2007-12-11

Re: routing policy based on u32 classifier

From: Marco Berizzi <hidden>
Date: 2007-12-11 11:13:06

Brian S Julin wrote:
Marco wrote:
quoted
Brian S Julin wrote:
quoted
Almost clear... why can you not just add "src <ADSL
IP>" to the fwmark
route to set the default source address for locally
originating
packets?
IIRC, it doesn't work because netfilter isn't called in
ip source address selection.
Ah I see. Referring to this diagram...

http://www.shorewall.net/images/Netfilter.png

...and to many people I see posting about similar issues,
you are correct in that. A process socket cannot default to
the correct (final) source address to use if there is a
fwmark
rule as it stands.

I'll take a wild guess and conjecture that the reason fwmark
rules work at all for output routing is that applying a
fwmark on OUTPUT/mangle constitutes "changing the packet"
and qualifies it for the NAT reroute. But by the time a
packet gets sent the source address has already been chosen.

About the only suggestion I can make is that "dumb nat"
might be more elegant if you are not already using it,
and looking into getting squid to explicitly set its
source address.
my solution is cleaner :-) the kernel select the ip for
squid and then it get SNATed.
Thanks for the feedback.
In fact it may be the case with some daemons
that even if this were fixed inside the kernel, they will
ignore the source address configured kernel side because they
explicitly set it (usually by a reverse of their "Listen"
configuration.) It's likely that this could be fixed and
squid require NAT still. Perhaps the best solution is
for individual daemons to be given configuration options
telling them what source addresses to use.

Has anyone worked up a patch already to do this kernel
side? I could see it being fairly complicated. You
would have to hand the packet directly to netfilter, then
have netfilter perform a first-run RPDB lookup only for
packets where it needs to (or packets which it decides
not to touch) and then a second RPDB lookup if the
packet is modified. Might speed things up a bit for
some cases as a side benefit but worth it? I don't
know.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help