From: Wim Ceulemans <wim.ceulemans@able.be>
To: Henrik Nordstrom <hno@marasystems.com>
Cc: netfilter-devel@lists.netfilter.org, dev@able.be
Subject: Re: Routing decision?
Date: Thu, 18 Sep 2003 09:37:25 +0200 [thread overview]
Message-ID: <3F6960B5.6050303@able.be> (raw)
In-Reply-To: <Pine.LNX.4.44.0309151802300.17421-100000@filer.marasystems.com>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
Henrik Nordstrom wrote:
>On Mon, 15 Sep 2003, Wim Ceulemans wrote:
>
>
>
>>If I understand correct, if the local endpoint of the socket is not
>>bound, then:
>>1. The routing decision is taken, and the source IP address is assigned
>>to the IP address of the interface
>> through which the packet would leave the firewall.
>>
>>
>
>Yes. Or to be more precise to the source IP address of the route by which
>the packet would leave the host, or interface address if no route source
>address is defined in the routing table.
>
>
>
>>2. The packet travels through the OUTPUT chain and does not pass the
>>routing decision anymore, because
>> the routing decision was already taken before going to the OUTPUT
>>chain.
>>
>>
>
>Yes.
>
>However on the next packet of the connection (assuming it is a TCP
>connection) the situation is the reverse. The local endpoint of the socket
>is now bound and there is no need for a routing decision during packet
>construction as the source IP address is already know. So now routing
>occurs after OUTPUT like it logically should be.
>
>
>
>>Is there any specific reason why the packet doesn't pass the routing
>>decision the second time?
>>
>>
>
>Why should it if the routing has already been called once?
>
>iptables does route the packet a second time if you mangle or NAT the
>packet.
>
>Regards
>Henrik
>
>
>
>
Henrik
Sorry to come back to this problem.
Wouldn't the firewall be more predictable if the routing decision was
always taken after the packet travels through the OUTPUT chain, even if
it was a packet originating from an unbound socket? In that way the
diagram in the netfilter tutorial would be true in all cases, and also if
advanced routing with the ip command is used, it would work with all
packets (originating from bound or unbound sockets).
Of course for packets originating from unbound sockets this would lead
to the fact that the routing decision code is gone through twice, but
the first time only for determining the source address, and the second
time to be able to re-route the packet to another interface (based on
marks set in the output chain).
Regards
Wim
--
Wim Ceulemans
R&D Engineer
Secure Internet Communication with aXs Guard
Able NV
Leuvensesteenweg 282 - B-3190 Boortmeerbeek - Belgium
Phone: + 32 15 50.44.00 - Fax: + 32 15 50.44.09
E-mail: wim.ceulemans@able.be
--
Security check on this e-mail has been done by aXs GUARD
(http://www.axsguard.com)
next prev parent reply other threads:[~2003-09-18 7:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-15 13:16 Routing decision? Wim Ceulemans
2003-09-15 14:34 ` Henrik Nordstrom
2003-09-15 15:29 ` Wim Ceulemans
2003-09-15 16:06 ` Henrik Nordstrom
2003-09-15 16:25 ` Wim Ceulemans
2003-09-15 16:59 ` Cedric Blancher
2003-09-15 19:48 ` Henrik Nordstrom
2003-09-18 7:37 ` Wim Ceulemans [this message]
2003-09-18 11:22 ` Henrik Nordstrom
2003-09-18 11:54 ` Wim Ceulemans
2003-09-18 13:10 ` Henrik Nordstrom
2003-09-18 13:39 ` Wim Ceulemans
-- strict thread matches above, loose matches on Subject: below --
2003-09-15 20:10 Daniel Chemko
2003-09-15 22:32 ` Henrik Nordstrom
2003-09-15 8:49 Wim Ceulemans
2003-09-15 9:08 ` Ray Leach
2003-09-15 10:44 ` Wim Ceulemans
2003-09-15 12:14 ` Ray Leach
2003-09-15 12:53 ` Wim Ceulemans
2003-09-15 13:09 ` Ray Leach
2003-09-15 13:31 ` Cedric Blancher
2003-09-15 13:46 ` Ray Leach
2003-09-15 14:00 ` Cedric Blancher
2003-09-15 15:03 ` Ray Leach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F6960B5.6050303@able.be \
--to=wim.ceulemans@able.be \
--cc=dev@able.be \
--cc=hno@marasystems.com \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.