Packet chain traversals

Packet chain traversals

[Joel Newkirk]

I've been working on a chain traversal diagram (primarily for my own reasons, 
but if anybody likes it they are welcome to use it non-commercially) and have 
a few questions.

First, the current form of the diagram is (temporarily) at 
http://newkirk.no-ip.org:83/Traversal-sm.png
and the basic rule is that a packet cannot cross a black line.  The choices of 
colors are meaningless, except to differentiate chains.

I know that the 'latest' form of netfilter has mangle AND filter chains for 
forward and input, and mangle, nat, and filter chains for output.  (Yeah, the 
diagram would be even more confusingly complicated with that detailed :^)

Can someone offer some examples of uses for mangle-forward, mangle-input, 
mangle-output, and nat-output?  I can't see much use for them, but my use of 
iptables has been fairly simple so far, and most of my comprehension is based 
on the previous version of the tutorial. (and absorbing the gobs of 
information embedded in messages here :^)

Also, I wanted to ask for clarification on a point in the latest 
iptables-tutorial "Traversing of tables and chains" section:  At one point it 
seems that packets pass through mangle-forward THEN filter-forward, (diagram) 
yet elsewhere it seems to be the reverse. (table 1)  Which is correct?

Thanks for any input, examples, diagram criticism (artistic or logical) etc.  
If your response seems to you to be useless to the list in general then 
please just send it to me directly.

j

-- 
"The problem with the French is that they don't have a word for entrepreneur." 
--George W. Bush

Re: Packet chain traversals

[Oskar Andreasson]

Hi Joel,

On Sun, 27 Oct 2002, Joel Newkirk wrote:

> I've been working on a chain traversal diagram (primarily for my own reasons, 
> but if anybody likes it they are welcome to use it non-commercially) and have 
> a few questions.
> 
> First, the current form of the diagram is (temporarily) at 
> http://newkirk.no-ip.org:83/Traversal-sm.png

Mmmmm, reminds me of that trip on LSD I took the other day.... =) just 
kidding. It does look good really, except you made it rather confusing in 
one aspect... I don't know if it's just me, but why do you have two "out" 
and two "in"?

> and the basic rule is that a packet cannot cross a black line.  The choices of 
> colors are meaningless, except to differentiate chains.
> 
> I know that the 'latest' form of netfilter has mangle AND filter chains for 
> forward and input, and mangle, nat, and filter chains for output.  (Yeah, the 
> diagram would be even more confusingly complicated with that detailed :^)
> 
> Can someone offer some examples of uses for mangle-forward, mangle-input, 
> mangle-output, and nat-output?  I can't see much use for them, but my use of 
> iptables has been fairly simple so far, and most of my comprehension is based 
> on the previous version of the tutorial. (and absorbing the gobs of 
> information embedded in messages here :^)
> 
> Also, I wanted to ask for clarification on a point in the latest 
> iptables-tutorial "Traversing of tables and chains" section:  At one point it 
> seems that packets pass through mangle-forward THEN filter-forward, (diagram) 
> yet elsewhere it seems to be the reverse. (table 1)  Which is correct?

I just fixed this today actually. If you want to make absolutely certain, 
run the script attached to the tutorial (I added an updated version to 
this mail since the one in the released tutorial doesn't contain the 
mangle5hooks.patch fixes), tail -f the proper logfile 
and then send ping's from different locations and directions (e.g., ping 
across the firewall, ping to the firewall and ping from the firewall). 
That way you will be able to make sure how it works.

> 
> Thanks for any input, examples, diagram criticism (artistic or logical) etc.  
> If your response seems to you to be useless to the list in general then 
> please just send it to me directly.

no problem. Don't take me too seriously though, I am a lousy "artist" 
so... :)

> 
> j
> 
> 

-- 
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: Packet chain traversals

[Oskar Andreasson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 198 bytes --]

Forgot to attach the script in question....

----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

[-- Attachment #2: Type: TEXT/plain, Size: 3305 bytes --]

#!/bin/bash
#
# rc.test-iptables - test script for iptables chains and tables.
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

#
# Filter table, all chains
#
iptables -t filter -A INPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter INPUT:"
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter INPUT:"
iptables -t filter -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter OUTPUT:"
iptables -t filter -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter OUTPUT:"
iptables -t filter -A FORWARD -p icmp --icmp-type echo-request \
-j LOG --log-prefix="filter FORWARD:"
iptables -t filter -A FORWARD -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="filter FORWARD:"

#
# NAT table, all chains except OUTPUT which don't work.
#
iptables -t nat -A PREROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat PREROUTING:"
iptables -t nat -A PREROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat PREROUTING:"
iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat POSTROUTING:"
iptables -t nat -A POSTROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat POSTROUTING:"
iptables -t nat -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="nat OUTPUT:"
iptables -t nat -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="nat OUTPUT:"

#
# Mangle table, all chains
#
iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle PREROUTING:"
iptables -t mangle -A PREROUTING -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle PREROUTING:"
iptables -t mangle -I FORWARD 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle FORWARD:"
iptables -t mangle -I FORWARD 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle FORWARD:"
iptables -t mangle -I INPUT 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle INPUT:"
iptables -t mangle -I INPUT 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle INPUT:"
iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle OUTPUT:"
iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle OUTPUT:"
iptables -t mangle -I POSTROUTING 1 -p icmp --icmp-type echo-request \
-j LOG --log-prefix="mangle POSTROUTING:"
iptables -t mangle -I POSTROUTING 1 -p icmp --icmp-type echo-reply \
-j LOG --log-prefix="mangle POSTROUTING:"

Re: Packet chain traversals

[Joel Newkirk]

On Sunday 27 October 2002 01:50 pm, Oskar Andreasson wrote:
> Hi Joel,
>
> On Sun, 27 Oct 2002, Joel Newkirk wrote:
> > I've been working on a chain traversal diagram (primarily for my own
> > reasons, but if anybody likes it they are welcome to use it
> > non-commercially) and have a few questions.
> >
> > First, the current form of the diagram is (temporarily) at
> > http://newkirk.no-ip.org:83/Traversal-sm.png
>
> Mmmmm, reminds me of that trip on LSD I took the other day.... =) just
> kidding. 

mmm.  about the resemblance, or the other day?  :^) (just kidding too :^)

> It does look good really, except you made it rather confusing in
> one aspect... I don't know if it's just me, but why do you have two "out"
> and two "in"?

Two reasons mostly:  That seems to reflect a common arrangement, where there 
is a single connection to the internet and a single connection to local 
network(s).  (feel free to label the top one 'ppp0' and the bottom 'eth1')  
It also allows the diagram to more clearly illustrate (to me at least) the 
situation where a packet can be sent back out the same interface it arrived 
from, such as a local DNAT redirection to another local IP.  Also, one or 
three (or more) would ruin the pretty symmetry...

In my mind, I always think of the local machine (local processes) as being 
'inside' the firewall, with the individual interfaces being separated by it, 
or the LAN being 'behind' it.  I can't think of a useful, non-degenerate 
example where this isn't a valid perspective, so I've held to it so far.

> > and the basic rule is that a packet cannot cross a black line.  The
> > choices of colors are meaningless, except to differentiate chains.

> > Also, I wanted to ask for clarification on a point in the latest
> > iptables-tutorial "Traversing of tables and chains" section:  At one
> > point it seems that packets pass through mangle-forward THEN
> > filter-forward, (diagram) yet elsewhere it seems to be the reverse.
> > (table 1)  Which is correct?
>
> I just fixed this today actually. If you want to make absolutely certain,
> run the script attached to the tutorial (I added an updated version to
> this mail since the one in the released tutorial doesn't contain the
> mangle5hooks.patch fixes), tail -f the proper logfile
> and then send ping's from different locations and directions (e.g., ping
> across the firewall, ping to the firewall and ping from the firewall).
> That way you will be able to make sure how it works.

Thanks.
> > Thanks for any input, examples, diagram criticism (artistic or logical)
> > etc. If your response seems to you to be useless to the list in general
> > then please just send it to me directly.
>
> no problem. Don't take me too seriously though, I am a lousy "artist"
> so... :)

I may be as well, but I've tired of always referring to a visualization that 
suited my perspective, and decided to try to make a printed version.  (BTW, 
my actual intention is to tweak then fade the colors out about 70% before 
printing a 'keeper', otherwise I'll have to cover it late in the evening... 
:^)

j

Re: Packet chain traversals

[Oskar Andreasson]

On Sun, 27 Oct 2002, Joel Newkirk wrote:

> On Sunday 27 October 2002 01:50 pm, Oskar Andreasson wrote:

> > > http://newkirk.no-ip.org:83/Traversal-sm.png
> >
> > Mmmmm, reminds me of that trip on LSD I took the other day.... =) just
> > kidding. 
> 
> mmm.  about the resemblance, or the other day?  :^) (just kidding too :^)

About the resemblance, of course;)

> 
> > It does look good really, except you made it rather confusing in
> > one aspect... I don't know if it's just me, but why do you have two "out"
> > and two "in"?
> 
> Two reasons mostly:  That seems to reflect a common arrangement, where there 
> is a single connection to the internet and a single connection to local 
> network(s).  (feel free to label the top one 'ppp0' and the bottom 'eth1')  
> It also allows the diagram to more clearly illustrate (to me at least) the 
> situation where a packet can be sent back out the same interface it arrived 
> from, such as a local DNAT redirection to another local IP.  Also, one or 
> three (or more) would ruin the pretty symmetry...

Ok, I can understand that reasoning. 

> 
> In my mind, I always think of the local machine (local processes) as being 
> 'inside' the firewall, with the individual interfaces being separated by it, 
> or the LAN being 'behind' it.  I can't think of a useful, non-degenerate 
> example where this isn't a valid perspective, so I've held to it so far.

Try a small backbone or so:).

> > > Thanks for any input, examples, diagram criticism (artistic or logical)
> > > etc. If your response seems to you to be useless to the list in general
> > > then please just send it to me directly.
> >
> > no problem. Don't take me too seriously though, I am a lousy "artist"
> > so... :)
> 
> I may be as well, but I've tired of always referring to a visualization that 
> suited my perspective, and decided to try to make a printed version.  (BTW, 
> my actual intention is to tweak then fade the colors out about 70% before 
> printing a 'keeper', otherwise I'll have to cover it late in the evening... 
> :^)

Sounds as a nice idea. I could use one myself once in a while (lousy 
memory). I would really like seeing the mangle/nat/filter stuff added to 
FORWARD/INPUT/OUTPUT though, and it would be even better:)

-- 
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: Packet chain traversals

[Joel Newkirk]

On Sunday 27 October 2002 04:23 pm, Oskar Andreasson wrote:
> On Sun, 27 Oct 2002, Joel Newkirk wrote:
> > On Sunday 27 October 2002 01:50 pm, Oskar Andreasson wrote:

> > In my mind, I always think of the local machine (local processes) as
> > being 'inside' the firewall, with the individual interfaces being
> > separated by it, or the LAN being 'behind' it.  I can't think of a
> > useful, non-degenerate example where this isn't a valid perspective, so
> > I've held to it so far.
>
> Try a small backbone or so:).
>
... :^)

> Sounds as a nice idea. I could use one myself once in a while (lousy
> memory). I would really like seeing the mangle/nat/filter stuff added to
> FORWARD/INPUT/OUTPUT though, and it would be even better:)

YWIMC.  (Anyone who tried to grab the pic this evening but couldn't I 
apologize - I broke down and rebooted to run Photoshop for a few minutes for 
curved text entry)  try http://newkirk.no-ip.org:83/Traversal-full.png (it's 
'full' sized at 2048x1600 and 'full' detail with all built-in chains listed)  
I'm probably going to give it a few days, then if I'm satisfied I'll rebuild 
it with cleaner text and spacing, and a few flow arrows.

BTW, I'm not happy already with one aspect, but can't see a resolution:  I 
look at this and picture a packet at 'in', then mangle-pre nat-pre and 
routing.  If it's forwarded then we have a quantum situation where it could 
'be' in either of the forward steps (semi-ovals?) and then to routing again 
BEFORE it is really decided which 'out' it is heading for.  Now I know how it 
really works, but when I look at this I expect the forwarding destination to 
already be determined before it hits Mangle Forward, just based on the 
diagram construction, and it actually isn't.  Oh, well.  Unless someone can 
suggest an alternative, I'll likely leave it as is. (Yes Oscar, I realized 
that splitting it to any half would eliminate this artifact... Damn... :^)

j

Problem With NAT to NAT with IPTABLES

[hare ram]

Hi all

i have DSL 2MB connection with my provider
he is authenticating and giving me 2MB Bandwidth
i am using for my internal office purpose

i have zyxel ADSL modem which is is Doing NAT
since i have lot of corporate users, i want to manage the bandwidth, so i
added another Redhat Linux box in between user and Zyxel ADSL router with 2
NIC
the set up look like below


Corporate users---NIC1--NIC2--ADSL LAN--ADLS WAN--UPLink/DownLink provider


the problem is iam getting very poor response when i use iptables NAT to NAT
configuration
the configuration is like this

Internal Users are using  192.168.2.5 to 192.168.2.200 subnet is
255.255.255.0
Internal user Gateway is (NIC1) 192.168.2.1

NIC2 IP address is 192.168.4.2 with the subnet if 255.255.255.0
ADSLLAN ip address is 192.168.4.1 with the Subnet if 255.255.255.0
NIC2 and ADSLLAN is connected with Cross cable

ADSL WAN ip address is Dynamic

This is what my present configuration of LAN
but iam getting very poor responce of browsing, when iam doing any of the PC
from corporate users

when i remove the Linux box , iam getting good speed, but its sharing the
bandwidth that, any one can pull 2MB, iam not able to monitor

in the Redhat Linux 7.3 iam running Squid and Transparent proxy, with
Iptables prerouting from 80 port to 3128
its able to serve the request but very slow responce, never gone yet to CBQ.

I have another Setup in another Office

Corporate users---NIC1--NIC2--Cisco LAN-- Cisco WAN--UPLink/DownLink
provider

here iam getting Cisco LAN is Public IP address, and My NIC2 also Public
Address
here my above setup working with any hassels

can any suggest me what is wrong, any recomendation on the above setup
where NAT to NAT giving problem

thanks in advance
hare

Re: Packet chain traversals

[Antony Stone]

On Sunday 27 October 2002 6:52 pm, Oskar Andreasson wrote:

> Forgot to attach the script in question....

Hi Oskar.

Just a small point which has me puzzled about the diagram:

Why do you have a routing decision between OUTPUT and NAT ?   What "decision" 
is there to be made ?

Antony.

-- 

G- GIT/E d- s+:--(-) a+ C++++$ UL++++$ P+(---)>++ L+++(++++)$ !E W(-) N(-) o? 
w-- O !M V+++(--) !PS !PE Y+ PGP+> t- tv@ b+++ DI++ D--- e++>+++ h++ r@? 5? 
!X- !R K--?

Re: Packet chain traversals

[Oskar Andreasson]

Hi Antony,

On Mon, 28 Oct 2002, Antony Stone wrote:

> On Sunday 27 October 2002 6:52 pm, Oskar Andreasson wrote:
> 
> > Forgot to attach the script in question....
> 
> Hi Oskar.
> 
> Just a small point which has me puzzled about the diagram:
> 
> Why do you have a routing decision between OUTPUT and NAT ?   What "decision" 
> is there to be made ?

When you bring it to light... I don't know... The statement is an artifact 
from the really really early stages of the tutorial, something like the 
second release I made. To my recollection someone mentioned it to me in a 
mail, but I am not sure. 

Noone has complained so far, and I haven't actually thought about it 
either so.... it's still there. 

Because of your mail, I started checking it out... and I can't actually 
find any "routing" decisions being made after NF_IP_LOCAL_OUT or before 
the IP_NF_POST_ROUTING, nor do any documents I found (so far) point any 
such point out, more than mine... ugly... really ugly.

I will check some more in the source code and see if I am really that off 
base. Comments are more than welcome!

----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: Packet chain traversals

[Antony Stone]

On Monday 28 October 2002 9:18 pm, Oskar Andreasson wrote:

> Hi Antony,
>
> On Mon, 28 Oct 2002, Antony Stone wrote:
> >
> > Why do you have a routing decision between OUTPUT and NAT ?   What
> > "decision" is there to be made ?
>
> When you bring it to light... I don't know...
>
> Because of your mail, I started checking it out... and I can't actually
> find any "routing" decisions being made after NF_IP_LOCAL_OUT or before
> the IP_NF_POST_ROUTING, nor do any documents I found (so far) point any
> such point out, more than mine...

The only thing I can think of is "which interface should this packet go out 
of", however that's certainly not the same sort of "decision" as there is 
between PREROUTING and INPUT or FORWARD, and I'm not even sure it belongs 
quite where it is shown...

The main reason I commented on it is that I would expect something labelled a 
"decision" to have more than one possible outcome (eg the first routing 
decision leads on to either INPUT or FORWARD depending on the destination 
address), whereas even for the question of which interface to use, this is 
not relevant to netfilter - there are no choices involved.

Anyway, just my 2c, as the saying goes...

Antony.

-- 

Most people are aware that the Universe is big.

 - Paul Davies, Professor of Theoretical Physics

Re: Packet chain traversals

[Matthew G. Marsh]

On Mon, 28 Oct 2002, Antony Stone wrote:

> On Monday 28 October 2002 9:18 pm, Oskar Andreasson wrote:
>
> > Hi Antony,
> >
> > On Mon, 28 Oct 2002, Antony Stone wrote:
> > >
> > > Why do you have a routing decision between OUTPUT and NAT ?   What
> > > "decision" is there to be made ?
> >
> > When you bring it to light... I don't know...
> >
> > Because of your mail, I started checking it out... and I can't actually
> > find any "routing" decisions being made after NF_IP_LOCAL_OUT or before
> > the IP_NF_POST_ROUTING, nor do any documents I found (so far) point any
> > such point out, more than mine...
>
> The only thing I can think of is "which interface should this packet go out
> of", however that's certainly not the same sort of "decision" as there is
> between PREROUTING and INPUT or FORWARD, and I'm not even sure it belongs
> quite where it is shown...

It does exist between OUTPUT and NAT. But the decision structure is more
along the lines of rule application. Thus you can issue rules such as:

ip rule add from 10.1.1.1 dev lo table mytable prio 13000

and any packet coming from the local machine (ie exiting OUTPUT) would
then be acted upon by this rule. see?

> The main reason I commented on it is that I would expect something labelled a
> "decision" to have more than one possible outcome (eg the first routing
> decision leads on to either INPUT or FORWARD depending on the destination
> address), whereas even for the question of which interface to use, this is
> not relevant to netfilter - there are no choices involved.
>
> Anyway, just my 2c, as the saying goes...
>
> Antony.
>
> --
>
> Most people are aware that the Universe is big.
>
>  - Paul Davies, Professor of Theoretical Physics
>

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------

Re: Packet chain traversals

[Antony Stone]

On Wednesday 30 October 2002 4:11 pm, Matthew G. Marsh wrote:

> > The only thing I can think of is "which interface should this packet go
> > out of", however that's certainly not the same sort of "decision" as
> > there is between PREROUTING and INPUT or FORWARD, and I'm not even sure
> > it belongs quite where it is shown...
>
> It does exist between OUTPUT and NAT. But the decision structure is more
> along the lines of rule application. Thus you can issue rules such as:
>
> ip rule add from 10.1.1.1 dev lo table mytable prio 13000
>
> and any packet coming from the local machine (ie exiting OUTPUT) would
> then be acted upon by this rule. see?

Fair enough, but I still don't think this is any sort of decision which 
affects netfilter (which would be the only point of putting it into the 
diagram, I think).

The only decisions of interest to netfilter are "is the packet local ?" and 
if not "which interface is it going out of ?".   Both of those have already 
been decided in the first routing decision, between prerouting and input / 
forward.

I'm not convinced there's any purpose in having another routing decision 
shown between output and postrouting, especially in a document which is aimed 
at beginners.

Regards,

Anton.

-- 

Success is a lousy teacher.   It seduces smart people into thinking they 
can't lose.

 - William H Gates III

Re: Packet chain traversals

[Matthew G. Marsh]

On Wed, 30 Oct 2002, Antony Stone wrote:

> On Wednesday 30 October 2002 4:11 pm, Matthew G. Marsh wrote:
>
> > > The only thing I can think of is "which interface should this packet go
> > > out of", however that's certainly not the same sort of "decision" as
> > > there is between PREROUTING and INPUT or FORWARD, and I'm not even sure
> > > it belongs quite where it is shown...
> >
> > It does exist between OUTPUT and NAT. But the decision structure is more
> > along the lines of rule application. Thus you can issue rules such as:
> >
> > ip rule add from 10.1.1.1 dev lo table mytable prio 13000
> >
> > and any packet coming from the local machine (ie exiting OUTPUT) would
> > then be acted upon by this rule. see?
>
> Fair enough, but I still don't think this is any sort of decision which
> affects netfilter (which would be the only point of putting it into the
> diagram, I think).
>
> The only decisions of interest to netfilter are "is the packet local ?" and
> if not "which interface is it going out of ?".   Both of those have already
> been decided in the first routing decision, between prerouting and input /
> forward.

Not completely true. fe: if the rule above takes affect then a packet may
have its outbound interface, source address, and next hop all changed by
the contents of table mytable. Illustrate by issuing the following:

ip rule add from 10.1.1.1 dev lo prohibit

This will prohibit all packets source addressed with 10.1.1.1 from leaving
the box. They are basically dropped no matter what your iptables settings
are. So if your eth0 internal network interface is addressed as
10.1.1.1 and you try to issue any ipv4 command from your firewall box it
will simply never leave. You could also try the following rule route
combo:

ip rule add from 10.1.1.1 dev lo table 1 prio 2

ip route add blackhole 11.1.1.0/24 table 1

This combo will simply drop any packet with internal source address
10.1.1.1 destined to 11.1.1.0/24 network. And iptables will never know.

You do need to see that the RPDB for IPv4 under Linux has several effects
upon the iptables structure. fe you can use FastNAT to change both source
and destination addresses of a packet from your box without the iptables
framework ever knowing. Such a change can really screw up your rules
unless you understand what happened.

ok?

> I'm not convinced there's any purpose in having another routing decision
> shown between output and postrouting, especially in a document which is aimed
> at beginners.
>
> Regards,
>
> Anton.
>
> --
>
> Success is a lousy teacher.   It seduces smart people into thinking they
> can't lose.
>
>  - William H Gates III
>

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------

Re: Packet chain traversals

[Joel Newkirk]

On Wednesday 30 October 2002 12:22 pm, Antony Stone wrote:
> On Wednesday 30 October 2002 4:11 pm, Matthew G. Marsh wrote:
> > > The only thing I can think of is "which interface should this packet go
> > > out of", however that's certainly not the same sort of "decision" as
> > > there is between PREROUTING and INPUT or FORWARD, and I'm not even sure
> > > it belongs quite where it is shown...
> >
> > It does exist between OUTPUT and NAT. But the decision structure is more
> > along the lines of rule application. Thus you can issue rules such as:

> The only decisions of interest to netfilter are "is the packet local ?" and
> if not "which interface is it going out of ?".   Both of those have already
> been decided in the first routing decision, between prerouting and input /
> forward.
>
> I'm not convinced there's any purpose in having another routing decision
> shown between output and postrouting, especially in a document which is
> aimed at beginners.

I'm planning to rebuild the diagram this weekend, in several forms from 
simplest (in/out/forward/local) to mid (in/out/forward/natpre/natpost/local) 
to full.  I've not yet decided if I'm going to have 'routing decision' in the 
diagram at all, since it seems that the only concrete placement of it is 
after prerouting, and the existence of multiple parts in the next layer 
inward (forward and input) makes the existance of SOME decision pretty 
apparent.  I may just wait until I have a better grasp of the interaction of 
Netfilter and Iproute2 and see where my understanding leads me for a possible 
generation 2 diagram.  :^)

Is there some way that I can expand on Oscar's packet tracking rules to also 
track when the packet hits routing?  I was wondering whether I could set a 
TOS in prerouting and output for testing purposes, and track incidents of 
that TOS in routing.

j