* Routing decision?
@ 2003-09-15 13:16 Wim Ceulemans
2003-09-15 14:34 ` Henrik Nordstrom
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 13:16 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi
In paragraph 6.2 of the iptables-tutorial the following is said:
"The OUTPUT chain is used for altering locally generated packets (i.e.,
on the firewall) before they get to the routing decision.
But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
see the "Routing decision" is listed after the "Local process" and
BEFORE! the packet goes to the output chain.
So which one is right? Does the routing decision take place after or
before the packet travels through the output chain?
Regards
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 13:16 Routing decision? Wim Ceulemans
@ 2003-09-15 14:34 ` Henrik Nordstrom
2003-09-15 15:29 ` Wim Ceulemans
0 siblings, 1 reply; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-15 14:34 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: netfilter-devel
On Mon, 15 Sep 2003, Wim Ceulemans wrote:
> In paragraph 6.2 of the iptables-tutorial the following is said:
> "The OUTPUT chain is used for altering locally generated packets (i.e.,
> on the firewall) before they get to the routing decision.
Yes.
> But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
> see the "Routing decision" is listed after the "Local process" and
> BEFORE! the packet goes to the output chain.
>
> So which one is right? Does the routing decision take place after or
> before the packet travels through the output chain?
Both, depending on the situation.
if the local endpoint of the socket sending the packet is bound then
routing occurs after OUTPUT.
If the local endpoint of the socket is NOT bound then routing occurs
before OUTPUT to assign the source address.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 14:34 ` Henrik Nordstrom
@ 2003-09-15 15:29 ` Wim Ceulemans
2003-09-15 16:06 ` Henrik Nordstrom
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 15:29 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netfilter-devel, pieter
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
Henrik
Thanks for your answer.
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.
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.
Is there any specific reason why the packet doesn't pass the routing
decision the second time?
Regards
Wim
Henrik Nordstrom wrote:
>On Mon, 15 Sep 2003, Wim Ceulemans wrote:
>
>
>
>>In paragraph 6.2 of the iptables-tutorial the following is said:
>>"The OUTPUT chain is used for altering locally generated packets (i.e.,
>>on the firewall) before they get to the routing decision.
>>
>>
>
>Yes.
>
>
>
>>But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
>>see the "Routing decision" is listed after the "Local process" and
>>BEFORE! the packet goes to the output chain.
>>
>>So which one is right? Does the routing decision take place after or
>>before the packet travels through the output chain?
>>
>>
>
>Both, depending on the situation.
>
>if the local endpoint of the socket sending the packet is bound then
>routing occurs after OUTPUT.
>
>If the local endpoint of the socket is NOT bound then routing occurs
>before OUTPUT to assign the source address.
>
>Regards
>Henrik
>
>
>
>
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: Routing decision?
2003-09-15 15:29 ` Wim Ceulemans
@ 2003-09-15 16:06 ` Henrik Nordstrom
2003-09-15 16:25 ` Wim Ceulemans
2003-09-18 7:37 ` Wim Ceulemans
0 siblings, 2 replies; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-15 16:06 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: netfilter-devel, pieter
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
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
1 sibling, 2 replies; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 16:25 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netfilter-devel, pieter
[-- Attachment #1: Type: text/plain, Size: 1909 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?
>
Here's why: if you want to mark packets in the OUTPUT chain that are
http traffic, based
on the destination port. And then based on that mark send the packets to
another routing table
added with the ip command.
>
>iptables does route the packet a second time if you mangle or NAT the
>packet.
>
>Regards
>Henrik
>
>
>
>
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 16:25 ` Wim Ceulemans
@ 2003-09-15 16:59 ` Cedric Blancher
2003-09-15 19:48 ` Henrik Nordstrom
1 sibling, 0 replies; 24+ messages in thread
From: Cedric Blancher @ 2003-09-15 16:59 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: Henrik Nordstrom, netfilter-devel, pieter
Le lun 15/09/2003 à 18:25, Wim Ceulemans a écrit :
> >Why should it if the routing has already been called once?
> Here's why: if you want to mark packets in the OUTPUT chain that are
> http traffic, based
> on the destination port. And then based on that mark send the packets to
> another routing table
> added with the ip command.
See below...
> >iptables does route the packet a second time if you mangle or NAT the
> >packet.
If the packet is altered in any way (mangling or NATing), then routing
is called again, because the change(s) can change routing decision.
Marking as you mentionned, but also TOS or source address can be routing
keys.
--
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 16:25 ` Wim Ceulemans
2003-09-15 16:59 ` Cedric Blancher
@ 2003-09-15 19:48 ` Henrik Nordstrom
1 sibling, 0 replies; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-15 19:48 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: netfilter-devel, pieter
On Mon, 15 Sep 2003, Wim Ceulemans wrote:
> Here's why: if you want to mark packets in the OUTPUT chain that are
> http traffic, based on the destination port. And then based on that mark
> send the packets to another routing table added with the ip command.
Then do so. iptables will make the needed re-routing of the packet when
the nfmark is modified.
But you can't use this to select the source IP address as this has already
been done and must be done before the packet is constructed (and sent to
iptables), however you can use NAT to rewrite the source IP address if not
assigned suitably or alternaively (preferred) have the application use a
suitable source IP address to begin with.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 16:06 ` Henrik Nordstrom
2003-09-15 16:25 ` Wim Ceulemans
@ 2003-09-18 7:37 ` Wim Ceulemans
2003-09-18 11:22 ` Henrik Nordstrom
1 sibling, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-18 7:37 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netfilter-devel, dev
[-- 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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-18 7:37 ` Wim Ceulemans
@ 2003-09-18 11:22 ` Henrik Nordstrom
2003-09-18 11:54 ` Wim Ceulemans
0 siblings, 1 reply; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-18 11:22 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: netfilter-devel, dev
On Thu, 18 Sep 2003, Wim Ceulemans wrote:
> 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).
The routing takes place before OUTPUT on unbound sockets as it is the
routing table who decides the source IP address to use if the socket is
unbound, and it is impossible to create the packet without having the
source address.
> 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).
Yes, and this is what happens when it is needed.
The kernel uses routing before output to find the source IP address.
Then when iptables changes the packet in such manner that the routing may
change it calls the routing again, but only if the packet is modified by
iptables.
If there is no changes in the packet details iptables does not call
routing again as it can be assumed the result will be the same as in the
first call.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-18 11:22 ` Henrik Nordstrom
@ 2003-09-18 11:54 ` Wim Ceulemans
2003-09-18 13:10 ` Henrik Nordstrom
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-18 11:54 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netfilter-devel, dev
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
Henrik Nordstrom wrote:
>On Thu, 18 Sep 2003, Wim Ceulemans wrote:
>
>
>
>>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).
>>
>>
>
>The routing takes place before OUTPUT on unbound sockets as it is the
>routing table who decides the source IP address to use if the socket is
>unbound, and it is impossible to create the packet without having the
>source address.
>
>
>
>>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).
>>
>>
>
>Yes, and this is what happens when it is needed.
>
>The kernel uses routing before output to find the source IP address.
>
>Then when iptables changes the packet in such manner that the routing may
>change it calls the routing again, but only if the packet is modified by
>iptables.
>
>If there is no changes in the packet details iptables does not call
>routing again as it can be assumed the result will be the same as in the
>first call.
>
>Regards
>Henrik
>
>
>
Henrik
Ok, but the problem is that setting a mark on the packet isn't
considered as a change to the packet, since marks only live in
the kernel and have no effect on the packet.
So, if I want to re-route the packet later on because for example it is
an http packet (destination port is 80, 1080 or 8080)
then I have to change something in the packet just to be able to
re-route it. But I don't want to change something in the
packet, I just want to re-route it to another interface based on the mark.
Do you have an idea how we could do this without using unbound packets?
Thanks and 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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-18 11:54 ` Wim Ceulemans
@ 2003-09-18 13:10 ` Henrik Nordstrom
2003-09-18 13:39 ` Wim Ceulemans
0 siblings, 1 reply; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-18 13:10 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: netfilter-devel, dev
On Thu, 18 Sep 2003, Wim Ceulemans wrote:
> Ok, but the problem is that setting a mark on the packet isn't
> considered as a change to the packet, since marks only live in
> the kernel and have no effect on the packet.
Changing marks are considered a change in the packet in this context.
If mangle OUTPUT changes any of Source IP, Destination IP, ToS or nfmark
then the packet is automatically rerouted by iptables.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-18 13:10 ` Henrik Nordstrom
@ 2003-09-18 13:39 ` Wim Ceulemans
0 siblings, 0 replies; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-18 13:39 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: netfilter-devel, dev
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Ok, thanks Henrik, we will try the mark in the mangle table.
Regards
Wim
Henrik Nordstrom wrote:
>On Thu, 18 Sep 2003, Wim Ceulemans wrote:
>
>
>
>>Ok, but the problem is that setting a mark on the packet isn't
>>considered as a change to the packet, since marks only live in
>>the kernel and have no effect on the packet.
>>
>>
>
>Changing marks are considered a change in the packet in this context.
>
>If mangle OUTPUT changes any of Source IP, Destination IP, ToS or nfmark
>then the packet is automatically rerouted by iptables.
>
>Regards
>Henrik
>
>
>
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Routing decision?
@ 2003-09-15 20:10 Daniel Chemko
2003-09-15 22:32 ` Henrik Nordstrom
0 siblings, 1 reply; 24+ messages in thread
From: Daniel Chemko @ 2003-09-15 20:10 UTC (permalink / raw)
To: Henrik Nordstrom, Wim Ceulemans; +Cc: netfilter-devel, pieter
I am trying to do something very similarly. I am having a heck of a time
managing to get this all working properly.
Setup:
Two interfaces: eth0(default), eth2
# Add routing table entries for eth2
ip route add default via <my isp gw> src <myip> dev eth2 table 100
ip rule add fwmark 1 table 100
# Add rule to forward to ISP #2
iptables -t mangle -A OUTPUT -p tcp --dport 80 -m state --state NEW -j
MARK --set-mark 1
The traffic is getting routed out of eth2, but any ARP requests sent out
of eth2 has the respond to field set too the IP address mapped to eth0.
Is there an ARP source address flag that isn't getting set right, or is
it just my wacky configuration?
I am using this with squid in userspace, and I am unaware of any way to
get squid to bind its outbound interface. If I could bind to just an IP
address which is normally the case, I still can't function without
hacking because the interfaces are on DHCP.
Sorry for the question in devel, but Netfilter general didn't come up
with a solution.
-----Original Message-----
From: Henrik Nordstrom [mailto:hno@marasystems.com]
Sent: Monday, September 15, 2003 12:49 PM
To: Wim Ceulemans
Cc: netfilter-devel@lists.netfilter.org; pieter@able.be
Subject: Re: Routing decision?
On Mon, 15 Sep 2003, Wim Ceulemans wrote:
> Here's why: if you want to mark packets in the OUTPUT chain that are
> http traffic, based on the destination port. And then based on that
mark
> send the packets to another routing table added with the ip command.
Then do so. iptables will make the needed re-routing of the packet when
the nfmark is modified.
But you can't use this to select the source IP address as this has
already
been done and must be done before the packet is constructed (and sent to
iptables), however you can use NAT to rewrite the source IP address if
not
assigned suitably or alternaively (preferred) have the application use a
suitable source IP address to begin with.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Routing decision?
2003-09-15 20:10 Daniel Chemko
@ 2003-09-15 22:32 ` Henrik Nordstrom
0 siblings, 0 replies; 24+ messages in thread
From: Henrik Nordstrom @ 2003-09-15 22:32 UTC (permalink / raw)
To: Daniel Chemko; +Cc: Wim Ceulemans, netfilter-devel, pieter
On Mon, 15 Sep 2003, Daniel Chemko wrote:
> I am using this with squid in userspace, and I am unaware of any way to
> get squid to bind its outbound interface.
See tcp_outgoing_address in squid.conf. Gives you powers way beyond what
can be done in iptables/policy routing for selecting which source address
to use (assuming the current STABLE release of Squid is used)
policy using based on source address is then trivial and does not even
need marks.
Regards
Henrik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Routing decision?
@ 2003-09-15 8:49 Wim Ceulemans
2003-09-15 9:08 ` Ray Leach
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 8:49 UTC (permalink / raw)
To: netfilter; +Cc: pieter
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi
In paragraph 6.2 of the iptables-tutorial the following is said:
"The OUTPUT chain is used for altering locally generated packets (i.e.,
on the firewall) before they get to the routing decision.
But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
see the "Routing decision" is listed after the "Local process" and
BEFORE! the packet goes to the output chain.
So which one is right? Does the routing decision take place after or
before the packet travels through the output chain?
Regards
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 8:49 Wim Ceulemans
@ 2003-09-15 9:08 ` Ray Leach
2003-09-15 10:44 ` Wim Ceulemans
0 siblings, 1 reply; 24+ messages in thread
From: Ray Leach @ 2003-09-15 9:08 UTC (permalink / raw)
To: Netfilter Mailing List
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On Mon, 2003-09-15 at 10:49, Wim Ceulemans wrote:
> Hi
>
> In paragraph 6.2 of the iptables-tutorial the following is said:
> "The OUTPUT chain is used for altering locally generated packets (i.e.,
> on the firewall) before they get to the routing decision.
>
> But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
> see the "Routing decision" is listed after the "Local process" and
> BEFORE! the packet goes to the output chain.
>
> So which one is right? Does the routing decision take place after or
> before the packet travels through the output chain?
Are you not getting confused with 'locally generated' and 'local
process'. They are not the same thing.
>
> Regards
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 9:08 ` Ray Leach
@ 2003-09-15 10:44 ` Wim Ceulemans
2003-09-15 12:14 ` Ray Leach
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 10:44 UTC (permalink / raw)
To: Netfilter Mailing List; +Cc: pieter
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
Hi Ray
In my opinion 'locally generated packets' can only be generated by a
local process.
So in the diagram where it says 'local process', that's where the
'locally generated packets' start
their way through the kernel. Where's the difference?
Regards
Wim
Ray Leach wrote:
>On Mon, 2003-09-15 at 10:49, Wim Ceulemans wrote:
>
>
>>Hi
>>
>>In paragraph 6.2 of the iptables-tutorial the following is said:
>>"The OUTPUT chain is used for altering locally generated packets (i.e.,
>>on the firewall) before they get to the routing decision.
>>
>>But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
>>see the "Routing decision" is listed after the "Local process" and
>>BEFORE! the packet goes to the output chain.
>>
>>So which one is right? Does the routing decision take place after or
>>before the packet travels through the output chain?
>>
>>
>
>Are you not getting confused with 'locally generated' and 'local
>process'. They are not the same thing.
>
>
>
>>Regards
>>
>>
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 10:44 ` Wim Ceulemans
@ 2003-09-15 12:14 ` Ray Leach
2003-09-15 12:53 ` Wim Ceulemans
0 siblings, 1 reply; 24+ messages in thread
From: Ray Leach @ 2003-09-15 12:14 UTC (permalink / raw)
To: Netfilter Mailing List
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
On Mon, 2003-09-15 at 12:44, Wim Ceulemans wrote:
> Hi Ray
>
> In my opinion 'locally generated packets' can only be generated by a
> local process.
> So in the diagram where it says 'local process', that's where the
> 'locally generated packets' start
> their way through the kernel. Where's the difference?
>
What about packets that get SNATed?
Where are they generated?
> Regards
> Wim
>
> Ray Leach wrote:
>
> >On Mon, 2003-09-15 at 10:49, Wim Ceulemans wrote:
> >
> >
> >>Hi
> >>
> >>In paragraph 6.2 of the iptables-tutorial the following is said:
> >>"The OUTPUT chain is used for altering locally generated packets (i.e.,
> >>on the firewall) before they get to the routing decision.
> >>
> >>But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
> >>see the "Routing decision" is listed after the "Local process" and
> >>BEFORE! the packet goes to the output chain.
> >>
> >>So which one is right? Does the routing decision take place after or
> >>before the packet travels through the output chain?
> >>
> >>
> >
> >Are you not getting confused with 'locally generated' and 'local
> >process'. They are not the same thing.
> >
> >
> >
> >>Regards
> >>
> >>
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 12:14 ` Ray Leach
@ 2003-09-15 12:53 ` Wim Ceulemans
2003-09-15 13:09 ` Ray Leach
0 siblings, 1 reply; 24+ messages in thread
From: Wim Ceulemans @ 2003-09-15 12:53 UTC (permalink / raw)
To: Ray Leach; +Cc: Netfilter Mailing List, pieter
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
Ray
Do you mean that if I masquerade all my packets behind the firewall,
that they are
considered as locally generated because due to the masquerading their
source IP is changed?
This would mean that these packets would travel through the FORWARD
chain and then through
the OUTPUT chain. And then the 'Kernel packet travelling diagram' would
be completely wrong,
because packets come only in the OUTPUT chain if they originate from a
local process.
Regards
Wim
Ray Leach wrote:
>On Mon, 2003-09-15 at 12:44, Wim Ceulemans wrote:
>
>
>>Hi Ray
>>
>>In my opinion 'locally generated packets' can only be generated by a
>>local process.
>>So in the diagram where it says 'local process', that's where the
>>'locally generated packets' start
>>their way through the kernel. Where's the difference?
>>
>>
>>
>What about packets that get SNATed?
>Where are they generated?
>
>
>
>>Regards
>>Wim
>>
>>Ray Leach wrote:
>>
>>
>>
>>>On Mon, 2003-09-15 at 10:49, Wim Ceulemans wrote:
>>>
>>>
>>>
>>>
>>>>Hi
>>>>
>>>>In paragraph 6.2 of the iptables-tutorial the following is said:
>>>>"The OUTPUT chain is used for altering locally generated packets (i.e.,
>>>>on the firewall) before they get to the routing decision.
>>>>
>>>>But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
>>>>see the "Routing decision" is listed after the "Local process" and
>>>>BEFORE! the packet goes to the output chain.
>>>>
>>>>So which one is right? Does the routing decision take place after or
>>>>before the packet travels through the output chain?
>>>>
>>>>
>>>>
>>>>
>>>Are you not getting confused with 'locally generated' and 'local
>>>process'. They are not the same thing.
>>>
>>>
>>>
>>>
>>>
>>>>Regards
>>>>
>>>>
>>>>
>>>>
--
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 12:53 ` Wim Ceulemans
@ 2003-09-15 13:09 ` Ray Leach
2003-09-15 13:31 ` Cedric Blancher
0 siblings, 1 reply; 24+ messages in thread
From: Ray Leach @ 2003-09-15 13:09 UTC (permalink / raw)
To: Wim Ceulemans; +Cc: Netfilter Mailing List, pieter
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
On Mon, 2003-09-15 at 14:53, Wim Ceulemans wrote:
> Ray
>
> Do you mean that if I masquerade all my packets behind the firewall,
> that they are
> considered as locally generated because due to the masquerading their
> source IP is changed?
>
> This would mean that these packets would travel through the FORWARD
> chain and then through
> the OUTPUT chain. And then the 'Kernel packet travelling diagram' would
> be completely wrong,
> because packets come only in the OUTPUT chain if they originate from a
> local process.
No, it was a question ... I don't think they are locally generated.
I think that the aliases on the interface have something to do with it.
I have had to add input and output rules in some situations to get DNAT
to work the way it is supposed to (redirect to a different destination).
It is strange.
>
> Regards
> Wim
>
> Ray Leach wrote:
>
> >On Mon, 2003-09-15 at 12:44, Wim Ceulemans wrote:
> >
> >
> >>Hi Ray
> >>
> >>In my opinion 'locally generated packets' can only be generated by a
> >>local process.
> >>So in the diagram where it says 'local process', that's where the
> >>'locally generated packets' start
> >>their way through the kernel. Where's the difference?
> >>
> >>
> >>
> >What about packets that get SNATed?
> >Where are they generated?
> >
> >
> >
> >>Regards
> >>Wim
> >>
> >>Ray Leach wrote:
> >>
> >>
> >>
> >>>On Mon, 2003-09-15 at 10:49, Wim Ceulemans wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi
> >>>>
> >>>>In paragraph 6.2 of the iptables-tutorial the following is said:
> >>>>"The OUTPUT chain is used for altering locally generated packets (i.e.,
> >>>>on the firewall) before they get to the routing decision.
> >>>>
> >>>>But in paragraph 3.1, the "Traversing of tables and chains" diagram, we
> >>>>see the "Routing decision" is listed after the "Local process" and
> >>>>BEFORE! the packet goes to the output chain.
> >>>>
> >>>>So which one is right? Does the routing decision take place after or
> >>>>before the packet travels through the output chain?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Are you not getting confused with 'locally generated' and 'local
> >>>process'. They are not the same thing.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Regards
> >>>>
> >>>>
> >>>>
> >>>>
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 13:09 ` Ray Leach
@ 2003-09-15 13:31 ` Cedric Blancher
2003-09-15 13:46 ` Ray Leach
0 siblings, 1 reply; 24+ messages in thread
From: Cedric Blancher @ 2003-09-15 13:31 UTC (permalink / raw)
To: Ray Leach; +Cc: Wim Ceulemans, Netfilter Mailing List, pieter
Le lun 15/09/2003 à 15:09, Ray Leach a écrit :
> I think that the aliases on the interface have something to do with it.
Nope.
When you DNAT an IP address that does not belong to your DNATing box,
there won't be anybody to answer prior router ARP requests on it, unless
you either set an alias up or tell this router that the IP as to get
routed through the DNATing box.
> I have had to add input and output rules in some situations to get DNAT
> to work the way it is supposed to (redirect to a different destination).
> It is strange.
Yes it is. I can get DNAT working without specifying any INPUT or OUTPUT
chain. Can you illustrate a situation for which you have to specify
INPUT and OUTPUT rules ?
--
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 13:31 ` Cedric Blancher
@ 2003-09-15 13:46 ` Ray Leach
2003-09-15 14:00 ` Cedric Blancher
0 siblings, 1 reply; 24+ messages in thread
From: Ray Leach @ 2003-09-15 13:46 UTC (permalink / raw)
To: Cedric Blancher; +Cc: Wim Ceulemans, Netfilter Mailing List, pieter
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
On Mon, 2003-09-15 at 15:31, Cedric Blancher wrote:
> Le lun 15/09/2003 à 15:09, Ray Leach a écrit :
> > I think that the aliases on the interface have something to do with it.
>
> Nope.
> When you DNAT an IP address that does not belong to your DNATing box,
> there won't be anybody to answer prior router ARP requests on it, unless
> you either set an alias up or tell this router that the IP as to get
> routed through the DNATing box.
>
> > I have had to add input and output rules in some situations to get DNAT
> > to work the way it is supposed to (redirect to a different destination).
> > It is strange.
>
> Yes it is. I can get DNAT working without specifying any INPUT or OUTPUT
> chain. Can you illustrate a situation for which you have to specify
> INPUT and OUTPUT rules ?
Sure.
My firewall machine currently has 5 NICs, each with their own ip (one
has a public ip - eth0)
eth0 has the public ip. It also has 10 alias ips.
eth1 has a private ip of 192.168.1.1.
eth1 network is my dmz with all the web servers from 192.168.1.165 to
192.168.1.173.
If I want to DNAT incoming traffic destined to on of the aliases bound
to interface eth0 to a server in the dmz - eth1 192.168.1.165 (for
example), then I need :
- a PREROUTING DNAT rule
- a FORWAORD rule for each direction (eth0 -> eth1 and eth1 -> eth0)
- and an INPUT rule for eth0 alias ip.
Does that make sense?
If I remove the INPUT rule, my DNAT does not work, the packets get sent
to the OUTPUT chain ...
Ray
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 13:46 ` Ray Leach
@ 2003-09-15 14:00 ` Cedric Blancher
2003-09-15 15:03 ` Ray Leach
0 siblings, 1 reply; 24+ messages in thread
From: Cedric Blancher @ 2003-09-15 14:00 UTC (permalink / raw)
To: Ray Leach; +Cc: Wim Ceulemans, Netfilter Mailing List, pieter
Le lun 15/09/2003 à 15:46, Ray Leach a écrit :
> My firewall machine currently has 5 NICs, each with their own ip (one
> has a public ip - eth0)
> eth0 has the public ip. It also has 10 alias ips.
> eth1 has a private ip of 192.168.1.1.
> eth1 network is my dmz with all the web servers from 192.168.1.165 to
> 192.168.1.173.
> If I want to DNAT incoming traffic destined to on of the aliases bound
> to interface eth0 to a server in the dmz - eth1 192.168.1.165 (for
> example), then I need :
> - a PREROUTING DNAT rule
> - a FORWAORD rule for each direction (eth0 -> eth1 and eth1 -> eth0)
> - and an INPUT rule for eth0 alias ip.
> Does that make sense?
Not to me. Supposing alias i set up (using iproute or ifconfig) I would
do this (and I think you did this) :
iptables -t nat -A PREROUTING -d $ALIAS -i eth0 -j DNAT \
--to 192.168.1.165
iptables -A FORWARD -d 192.168.1.165 -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -s 192.168.1.165 -i eth1 -o eth0 -j ACCEPT
And that's all to set a DNAT for incoming packets.
> If I remove the INPUT rule, my DNAT does not work, the packets get sent
> to the OUTPUT chain ...
What is the INPUT rule ? Once your packet gets DNATed in PREROUTING, it
is not sent to NF_IP_LOCAL_IN, but to NF_IP_FORWARD. Thus, it does not
cross filter table INPUT chain. If packets go through INPUT chain, that
means they're still destined to the alias IP, so that the DNAT rule did
not match them.
And I do not see how packets could go to OUTPUT chain as they're
supposed to get routed, not locally generated... The only case I see is
REDIRECT target use on a local proxy, so packets go through INPUT, then
proxy reply sent through OUTPUT chain.
I'm a bit lost on this one.
--
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Routing decision?
2003-09-15 14:00 ` Cedric Blancher
@ 2003-09-15 15:03 ` Ray Leach
0 siblings, 0 replies; 24+ messages in thread
From: Ray Leach @ 2003-09-15 15:03 UTC (permalink / raw)
To: Cedric Blancher; +Cc: Wim Ceulemans, Netfilter Mailing List, pieter
[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]
On Mon, 2003-09-15 at 16:00, Cedric Blancher wrote:
> Le lun 15/09/2003 à 15:46, Ray Leach a écrit :
> > My firewall machine currently has 5 NICs, each with their own ip (one
> > has a public ip - eth0)
> > eth0 has the public ip. It also has 10 alias ips.
> > eth1 has a private ip of 192.168.1.1.
> > eth1 network is my dmz with all the web servers from 192.168.1.165 to
> > 192.168.1.173.
> > If I want to DNAT incoming traffic destined to on of the aliases bound
> > to interface eth0 to a server in the dmz - eth1 192.168.1.165 (for
> > example), then I need :
> > - a PREROUTING DNAT rule
> > - a FORWAORD rule for each direction (eth0 -> eth1 and eth1 -> eth0)
> > - and an INPUT rule for eth0 alias ip.
> > Does that make sense?
>
> Not to me. Supposing alias i set up (using iproute or ifconfig) I would
> do this (and I think you did this) :
>
> iptables -t nat -A PREROUTING -d $ALIAS -i eth0 -j DNAT \
> --to 192.168.1.165
> iptables -A FORWARD -d 192.168.1.165 -i eth0 -o eth1 -j ACCEPT
> iptables -A FORWARD -s 192.168.1.165 -i eth1 -o eth0 -j ACCEPT
>
> And that's all to set a DNAT for incoming packets.
>
> > If I remove the INPUT rule, my DNAT does not work, the packets get sent
> > to the OUTPUT chain ...
>
> What is the INPUT rule ? Once your packet gets DNATed in PREROUTING, it
> is not sent to NF_IP_LOCAL_IN, but to NF_IP_FORWARD. Thus, it does not
> cross filter table INPUT chain. If packets go through INPUT chain, that
> means they're still destined to the alias IP, so that the DNAT rule did
> not match them.
> And I do not see how packets could go to OUTPUT chain as they're
> supposed to get routed, not locally generated... The only case I see is
> REDIRECT target use on a local proxy, so packets go through INPUT, then
> proxy reply sent through OUTPUT chain.
Now that's a possibility! I didn't even think of that. I do have a
transparent squid proxy running on that machine.
I suppose I was watching the traffic going through the proxy (probably
because I was testing from a local machine).
Thanks
>
> I'm a bit lost on this one.
--
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28
--
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-09-18 13:39 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.