All of lore.kernel.org
 help / color / mirror / Atom feed
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)


  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.