is this the zillionth mail asking for this detail?

is this the zillionth mail asking for this detail?

[Edmundo Carmona]

Hi, guys!

This is my very first post here... and I want it to be meaningful...
at least to myself. :)

I don't think I'm that smart to be the first to need this feature...
so I hope I'm the ONE vote that flips the balance to convince
netfilter developers that this is indeed <i>good and necessary</i>.

Why is the routing decision made before the packets hit OUTPUT? I know
that in OUTPUT it's already necessary to know what network interface
the packet will go through but then is it wrong to do policy routing
on output traffic? I don't think so.

Maybe a new chain could be used to do some PREROUTING actions (like
marking) before the routing decision is made for output traffic.

What do you think?

Re: is this the zillionth mail asking for this detail?

[/dev/rob0]

Edmundo Carmona wrote:
> I don't think I'm that smart to be the first to need this feature...
> so I hope I'm the ONE vote that flips the balance to convince
> netfilter developers that this is indeed <i>good and necessary</i>.

I am not sure we have developers posting here regularly. I've seen 
Harald Welte, but not often. I just looked and see that Jozsef 
Kadlecsik, who does post here, is on the Core Team.

> Maybe a new chain could be used to do some PREROUTING actions (like
> marking) before the routing decision is made for output traffic.

Is there any reason you can't use mangle/PREROUTING or nat/PREROUTING 
for what you need? What would filter/PREROUTING provide that those do 
not? In fact, although I don't do anything with mangle, I thought 
marking was in mangle territory.

 > What do you think?

Perhaps you should try to make your case on the developers' list.
-- 
     mail to this address is discarded unless "/dev/rob0"
     or "not-spam" is in Subject: header

Re: is this the zillionth mail asking for this detail?

[Jozsef Kadlecsik]

On Thu, 21 Jul 2005, /dev/rob0 wrote:

> Edmundo Carmona wrote:
> > I don't think I'm that smart to be the first to need this feature...
> > so I hope I'm the ONE vote that flips the balance to convince
> > netfilter developers that this is indeed <i>good and necessary</i>.
>
> I am not sure we have developers posting here regularly. I've seen
> Harald Welte, but not often. I just looked and see that Jozsef
> Kadlecsik, who does post here, is on the Core Team.

Just as time permits, alas...

> > Maybe a new chain could be used to do some PREROUTING actions (like
> > marking) before the routing decision is made for output traffic.
>
> Is there any reason you can't use mangle/PREROUTING or nat/PREROUTING
> for what you need? What would filter/PREROUTING provide that those do
> not? In fact, although I don't do anything with mangle, I thought
> marking was in mangle territory.

The original post was about locally generated packets and OUTPUT chain.

There's no need for extra hooks, because the routing engine is called
after the OUTPUT chain as well:

local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain

No problem with policy routing for the locally generated traffic.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: is this the zillionth mail asking for this detail?

[Jan Engelhardt]

>local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain
>
>No problem with policy routing for the locally generated traffic.

This sounds like a total overhead calculating the route twice.



Jan Engelhardt
-- 

Re: is this the zillionth mail asking for this detail?

[Jozsef Kadlecsik]

On Thu, 21 Jul 2005, Jan Engelhardt wrote:

> >local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain
> >
> >No problem with policy routing for the locally generated traffic.
>
> This sounds like a total overhead calculating the route twice.

The first one is required to fill out output device for the packet. The
second one is there to give chance to play with routing in OUTPUT.

This is traffic, generated locally, on the firewall.
You should run nothing on your firewall ;-)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: is this the zillionth mail asking for this detail?

[Jörg Harmuth]

Jozsef Kadlecsik schrieb:
> On Thu, 21 Jul 2005, Jan Engelhardt wrote:
> 
> 
>>>local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain
>>>
>>>No problem with policy routing for the locally generated traffic.
>>
>>This sounds like a total overhead calculating the route twice.
> 
> 
> The first one is required to fill out output device for the packet. The
> second one is there to give chance to play with routing in OUTPUT.

Still only 95% clear to me. You say, the second routing decision takes
place right after filter/OUTPUT ? And if so, do packets after
filter/FORWARD have this second routing decision too ?

Have a nice time,

Joerg

Re: is this the zillionth mail asking for this detail?

[Jozsef Kadlecsik]

On Thu, 21 Jul 2005, [ISO-8859-1] Jörg Harmuth wrote:

> >>>local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain
> >>>
> >>>No problem with policy routing for the locally generated traffic.
> >>
> >>This sounds like a total overhead calculating the route twice.
> >
> > The first one is required to fill out output device for the packet. The
> > second one is there to give chance to play with routing in OUTPUT.
>
> Still only 95% clear to me. You say, the second routing decision takes
> place right after filter/OUTPUT ? And if so, do packets after
> filter/FORWARD have this second routing decision too ?

No, that's the forward path.

But for the record: for locally generated packets the routing engine is
called after OUTPUT only if source address, destination address, nfmark
field or tos of the skbuff changed. So it's not called blindly for every
packet.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: is this the zillionth mail asking for this detail?

[Edmundo Carmona]

> 
> But for the record: for locally generated packets the routing engine is
> called after OUTPUT only if source address, destination address, nfmark
> field or tos of the skbuff changed. So it's not called blindly for every
> packet.
> 
> Best regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
> 
> 
Good to know!

Re: is this the zillionth mail asking for this detail?

[Edmundo Carmona]

Sorry to reply on an old thread.. but I think it's a good point to
start my next questions. Does the same policy stand on FORWARD? There
will be another routing decision if source address, destination
address, nfmark field or tos of the skbuff changed???

On 7/21/05, Edmundo Carmona <eantoranz@gmail.com> wrote:
> >
> > But for the record: for locally generated packets the routing engine is
> > called after OUTPUT only if source address, destination address, nfmark
> > field or tos of the skbuff changed. So it's not called blindly for every
> > packet.
> >
> > Best regards,
> > Jozsef
> > -
> > E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> > Address : KFKI Research Institute for Particle and Nuclear Physics
> >           H-1525 Budapest 114, POB. 49, Hungary
> >
> >
> Good to know!
>

Re: is this the zillionth mail asking for this detail?

[Jozsef Kadlecsik]

On Wed, 10 Aug 2005, Edmundo Carmona wrote:

> Sorry to reply on an old thread.. but I think it's a good point to
> start my next questions. Does the same policy stand on FORWARD? There
> will be another routing decision if source address, destination
> address, nfmark field or tos of the skbuff changed???

No. Those can be changed in PREROUTING and not in FORWARD.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: is this the zillionth mail asking for this detail?

[/dev/rob0]

[ top-posting fixed ]
On Wednesday 2005-August-10 10:37, Edmundo Carmona wrote:
> On 7/21/05, Edmundo Carmona <eantoranz@gmail.com> wrote:
> > > But for the record: for locally generated packets the routing
> > > engine is called after OUTPUT only if source address, destination
> > > address, nfmark field or tos of the skbuff changed. So it's not
> > > called blindly for every packet.

> Sorry to reply on an old thread.. but I think it's a good point to
> start my next questions. Does the same policy stand on FORWARD? There
> will be another routing decision if source address, destination
> address, nfmark field or tos of the skbuff changed???

Of which FORWARD are you asking, filter or mangle? In either case I 
think the routing decision has already been made. In neither case 
(TTBOMK; I don't know much about mangle) can you change source and 
destination IP addresses. Why would there be another routing decision?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: is this the zillionth mail asking for this detail?

[Edmundo Carmona]

I know the routing decision has been made.... but I thought there
could be a second routing decision... just like OUTPUT (there will be
a second routing decision if some properties from the packet were
mangled... or natted).

On 8/10/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> [ top-posting fixed ]
> On Wednesday 2005-August-10 10:37, Edmundo Carmona wrote:
> > On 7/21/05, Edmundo Carmona <eantoranz@gmail.com> wrote:
> > > > But for the record: for locally generated packets the routing
> > > > engine is called after OUTPUT only if source address, destination
> > > > address, nfmark field or tos of the skbuff changed. So it's not
> > > > called blindly for every packet.
> 
> > Sorry to reply on an old thread.. but I think it's a good point to
> > start my next questions. Does the same policy stand on FORWARD? There
> > will be another routing decision if source address, destination
> > address, nfmark field or tos of the skbuff changed???
> 
> Of which FORWARD are you asking, filter or mangle? In either case I
> think the routing decision has already been made. In neither case
> (TTBOMK; I don't know much about mangle) can you change source and
> destination IP addresses. Why would there be another routing decision?
> --
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
> 
>

Re: is this the zillionth mail asking for this detail?

[Jan Engelhardt]

>Sorry to reply on an old thread.. but I think it's a good point to
>start my next questions. Does the same policy stand on FORWARD? There
>will be another routing decision if source address, destination
>address, nfmark field or tos of the skbuff changed???

No, that's too late. You can only change the src/dst addresses in the nat 
table, which comes before the routing decision. If you write a module for 
-t mangle which then pokes on the addr, you're probably too late, i.e. no 
routing.

You might however, force a rerouting decision when using the -j ROUTE target.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: is this the zillionth mail asking for this detail?

[Edmundo Carmona]

I'm jumping on one leg! Forgive me if I don't sound serious right now.

Yeah... no service on the firewall, right? :-) That's absolutely not
the case of this particular firewall. Not like I have a networking lab
in the firewall... but there's squid and VPN (at least).

I want to make sure I got it right:

Suppose I have three internet connections.

I will load-balance two of them and leave one out just for VPN
connections and other services. According to what you are saying, I
could mark the packets in mangle-output that come from the VPN service
and then force them to go out with a rule that uses that firewall
mark.... right?

Thank you very much for your feedback!

Note:
It's not like I'm freaky and I just want to load balance two of them
leaving one out. I COUDLN'T get to load balance all three. After some
experimentation I noticed that two of the interfaces didn't get along
very well to make a multipath routing. I think it's because they're
both on the same network. Maybe you know of some multipath guru that
could help me with this so I can load-balance all of them.



On 7/21/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> On Thu, 21 Jul 2005, Jan Engelhardt wrote:
> 
> > >local process -> routing -> OUTPUT chain -> routing -> POSTROUTING chain
> > >
> > >No problem with policy routing for the locally generated traffic.
> >
> > This sounds like a total overhead calculating the route twice.
> 
> The first one is required to fill out output device for the packet. The
> second one is there to give chance to play with routing in OUTPUT.
> 
> This is traffic, generated locally, on the firewall.
> You should run nothing on your firewall ;-)
> 
> Best regards,
> Jozsef
> -
> E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
> Address : KFKI Research Institute for Particle and Nuclear Physics
>           H-1525 Budapest 114, POB. 49, Hungary
> 
>

Re: is this the zillionth mail asking for this detail?

[Jan Engelhardt]

>It's not like I'm freaky and I just want to load balance two of them
>leaving one out. I COUDLN'T get to load balance all three. After some
>experimentation I noticed that two of the interfaces didn't get along
>very well to make a multipath routing. I think it's because they're
>both on the same network. Maybe you know of some multipath guru that
>could help me with this so I can load-balance all of them.

Load balancing using route path cost and tc is done on a per-device basis;



Jan Engelhardt
-- 

Re: is this the zillionth mail asking for this detail?

[Edmundo Carmona]

Oh, I think I see what you mean.

That multipath thing is driving me crazy, man.

I just tested what Jozsef told us,  that there's a routing decision
right after output if something changed in the packet. He is so right!
I marked a packet in the output mangle, and it was routed according to
that mark.

Thank you, Jozsef!

On 7/21/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >>> I think it's because they're both on the same network.
> >>
> >> Load balancing using route path cost and tc is done on a per-device basis;
> >
> >Oh, ok. Good! (I need a translator!).
> >What do you mean? I didn't get it. (I'm kind of ashamed :-)).
> 
> If you do load balancing / traffic shaping using iptables, you operate on a
> per-packet or per-connection basis (depending on what you do)
> 
> If you do load balancing with /sbin/route, you operate at the device level.
> If you do traffic shaping with /sbin/tc, you operate at the device level.
> 
> 
> 
> Jan Engelhardt
> --
>