routing policy based on u32 classifier

routing policy based on u32 classifier

[pupilla]

Hello everyone,

Kindly I would like to ask if there is a way to do routing
policy based on u32 classifier without fwmark/netfilter.
I have read doc/tc-filters and doc/actions/actions-general
from iproute2-4.9.0 package but I am not able to find any
actions doing this kind of job: the only way is to mark
packets with netfilter.

Any response are welcome

TIA

Marco

routing policy based on u32 classifier

[Marco Berizzi]

Hello everybody.
Kindly, I would like to know if the is any plan
to add this feature to a future kernel release.
I know that fwmark is able to do this, but there
is the limitation in source ip address selection.

TIA

RE: routing policy based on u32 classifier

[Brian S Julin]

Marco wrote:

> Hello everybody.
> Kindly, I would like to know if the is any plan to add this feature to a future kernel release.
> I know that fwmark is able to do this, but there is the limitation in source ip address selection.

Could you explain the limitation?  My iptables manpage seems to suggest
that u32 is pretty general.  Are you just asking if the pom-ng ipt_u32
will be mainlined?

Re: routing policy based on u32 classifier

[Marco Berizzi]

Brian S Julin wrote:

Marco wrote:

> > Hello everybody.
> > Kindly, I would like to know if the is any plan to add this feature
to a > > future kernel release.
> > I know that fwmark is able to do this, but there is the limitation
in
> > source ip address selection.

> Could you explain the limitation?

Indeed.
Here is an example:

    hdsl|  |adsl
    line|  |line
        |  |
      +------+
      |      |
      |SQUID |
      |      |
      +------+
          |
  internal|
    lan   |


The linux default gateway point to the hdsl
router. I want to redirect the squid http
traffic (running on the same host) to the adsl
line. So I create a routing table (adsl table)
and I put a default route to the adsl router.
I mark the http traffic. I insert a rule
based on fwmark which select the 'adsl table'.
So far, so good. But, squid will select the
source ip address from the hdsl network class,
because it is the default gateway.
Then, the local generated packets must be SNATed
with the adsl ip.
Is it clear?

Re: routing policy based on u32 classifier

[Marco Berizzi]

Brian S Julin wrote:

> 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.

Re: routing policy based on u32 classifier

[Marco Berizzi]

Brian S Julin wrote:

> Marco wrote:
>
>> Brian S Julin wrote:
>>> 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.
>