Hi Matthew,
After reading your explanation I'm still in the dark.
1) Joe's question was: If one wants to mark the locally
generated packets based on the src address in the mangle
table, OUTPUT chain (that is where the routing decision
has not yet been made) can it be the case that you
mark a packet because the src at that point was A
and when the routing decision is made that src becomes B.
Or another version of the question has nothing to
do with netfilter and marking: when you want to
make a routing decision based on the src for a locally
generated packet, how can you do that when you have
entries like:
10.0.5.0/24 dev vlan5 proto kernel scope link src 10.0.5.2
10.0.6.0/24 dev vlan6 proto kernel scope link src 10.0.6.2
Let's say you decide to route the packets with src 10.0.5.2
to go out through vlan6, doesn't the routing subsystem change
the src to 10.0.6.2, as the entry suggests.
2) And my question was: a set of "equalize" routes towards a
certain destination doesn't seem to work. How come?
Ramin
On Wed, Jun 26, 2002 at 08:51:35AM -0500, Matthew G. Marsh wrote:
>
> Hi! I just got back Monday from a trip. Finally got to this message...
> Hope I'm not too late. Joe - could you give me the skinny on what sequence
> of rules you are using?
>
> There are several distinct interaction points between NetFilter and
> Netlink (ip utility stuff). Especially if you do some NAT wherein you end
> up calling the route structure yet again.
>
> Some answers included below:
>
> On Wed, 12 Jun 2002, Ramin Alidousti wrote:
>
> > Good question. It gets even worse: when I add a set
> > of "equalize" routes towards a certain destination,
> > it only round-robins for the transit packets but the
> > locally generated packets keep going out through the
> > same interface all the time, even if the src is set
> > to a loopback (dummy) address.
> >
> > Here is Matthew Marsh the man!!
> > Matthew, can you shed some light on these issues?
> >
> > Ramin
> >
> > On Tue, Jun 11, 2002 at 05:51:00PM -0400, Joe Patterson wrote:
> >
> > > I've got a kind of an odd setup, and am curious about something.
> > >
> > > I've seen some references that say that one should be able to set an fwmark
> > > on a packet in the mangle/OUTPUT chain, and then have the linux policy
> > > routing database determine the route to use based on that fwmark. I'm a
> > > little confused as to the order in which this happens. I would think that
> > > in order to be able to hand a packet to netfilter, it'd have to be a pretty
> > > complete packet, including things like the source IP address. However, the
> > > source address of a localy generated packet is determined by which route it
> > > matches. But you can't know which route it matches unless you have all of
> > > the information, such as the fwmarks.
>
> Yep - The actual best diagram to refer to is the old IPCHAINS packet path
> diagram as it does show the dual reference to the route structure.
> Essentially what happens is that the packet is generated and when it is
> generated the IP addressing parts of the header aer installed - BUT -
> the packet is issued from "localhost" and thus appears to be "coming from"
> loopback interface. Then it enters OUTPUT and can get mangled. However the
> RPDB is then called again as the packet addressing has changed. ?sense?
>
> > > It seems to me to be a bit of a chicken-and-egg thing. Or is the source
> > > address determined first, based on the route that the packet will *probably*
> > > take, then it's shipped through mangle/OUTPUT, then the real routing
> > > decision is made?
>
> No such "real" routing ;-}
>
> Basically all routing is real. Packet gen -> addressing applied; Packet
> OUTPUT Mangle -> RPDB call (routing); Packet leaves -> interface.
>
> Bear in mind that the Linux IPv4 Network stack is completely
> {internalized,virtualized}. An IPv4 packet "exists" with reference to the
> service it defines and has nothing whatsoever to do with the physical
> interfaces of the system. When you start then considering where in this
> scheme the NetFilter hooks are performed you can see that the interfaces
> are not to be considered and that the RPDB perfuses within and around the
> NetFilter structure. Thus the concept that the packet can only be "routed"
> at a specific point is not quite true except in the "this line of code
> does..." sense. In reality the NetFilter architecture handles the packet
> at specific points within the network stack. The network stack in between
> these points taps directly into the RPDB becuase the RPDB essentially "is"
> the network stack and thus the "routing" process is continuous. Hmmm - eh
> - examples are easier to understand for concreteness.
>
> > > This is kind of halfway between netfilter and lartc, but I figured someone
> > > here might know better than I.
> > >
> > > Thanks,
> > >
> > > -Joe Patterson, CCNP, CISSP
> > > Senior Security Engineer
> > > The Asgard Group
> > > (954)343-4370 x102
> > > [EMAIL PROTECTED]
>
> Feel free to holler my way... Thanks!
>
> --------------------------------------------------
> Matthew G. Marsh, President
> Paktronix Systems LLC
> 1506 North 59th Street
> Omaha NE 68104
> Phone: (402) 932-7250 x101
> Email: [EMAIL PROTECTED]
> WWW: http://www.paktronix.com
> --------------------------------------------------
