From: "Lluís Batlle" <viriketo@gmail.com>
To: lartc@mailman.ds9a.nl, netfilter@lists.netfilter.org
Subject: [LARTC] About routing, nat, the FORWARD chain,
Date: Wed, 06 Jul 2005 08:57:40 +0000 [thread overview]
Message-ID: <45219fb005070601577205f256@mail.gmail.com> (raw)
Hi!
I'm still trying to solve the problem, about which I already posted in
these lists... I've been trying to understand where packet routing and
NAT is being done. The schemes are quite clear, when it's about the
_first_ packet of a NAT connection (when it enters the NAT table). But
it isn't that clear about the packets NAT'ed by the connection
tracker.
Concretely about tcp connections, I've noticed that:
1. _no_ packet matches any chain of the 'nat' table, unless it's a SYN
tcp packet (start of connection). For the rest of the packets, they
don't match any chain of the 'nat' table.
2. The routing is done _before_ applying the rules of the FORWARD
chain. So, logging NAT connections (already made), shows that the
packets already have an output device. Example: "iptables -A FORWARD
-j LOG -o eth2", with example result:
Jul 6 10:18:29 thecrow IN=eth0 OUT=eth2 SRC\x192.168.4.20
DSTb.57.136.215 LENR TOS=0x00 PREC=0x00 TTLc IDF487 DF
PROTO=TCP SPT3967 DPT€ WINDOWc712 RES=0x00 ACK URGP=0
3. The NAT applied by the connection tracker (not by 'nat' table) is
done _after_ the FORWARD chain of the filter table. I SNAT all
starting connections packets (table nat, chain POSTROUTING) to
192.168.16.1/24 or 192.168.17.1/24, and you may see in the last
example that the source address still is that of the LAN
(192.168.4.4/20).
4. I can say the same as in the third point about the chain FORWARD of
the 'mangle' table.
So.... I don't know how people do "multihop routing + NAT" without
Julian's patches. It's obvious that:
1. The connection tracker doesn't keep information about the devices
involved in the connection.
2. The routing policy database is asked BEFORE the FORWARD or
POSTROUTING chains. In fact, that's why the 'nat'/POSTROUTING chains
know to which IP change the source address (that is, according to the
selected output device by, for instance, the 'equalize' of a multihop
route).
May someone clarify, how people do that kind of multihop routing + NAT
without any patch? I've read that some people does that. IMO, those
configurations don't work fine. Can someone suggest any patch, in
order to get routing _after_ the connection tracking NAT is made?
Am I wrong in something?
Thanks in advance!
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
WARNING: multiple messages have this Message-ID (diff)
From: "Lluís Batlle" <viriketo@gmail.com>
To: lartc@mailman.ds9a.nl, netfilter@lists.netfilter.org
Subject: About routing, nat, the FORWARD chain, and a bit of Julian's patches
Date: Wed, 6 Jul 2005 10:57:40 +0200 [thread overview]
Message-ID: <45219fb005070601577205f256@mail.gmail.com> (raw)
Hi!
I'm still trying to solve the problem, about which I already posted in
these lists... I've been trying to understand where packet routing and
NAT is being done. The schemes are quite clear, when it's about the
_first_ packet of a NAT connection (when it enters the NAT table). But
it isn't that clear about the packets NAT'ed by the connection
tracker.
Concretely about tcp connections, I've noticed that:
1. _no_ packet matches any chain of the 'nat' table, unless it's a SYN
tcp packet (start of connection). For the rest of the packets, they
don't match any chain of the 'nat' table.
2. The routing is done _before_ applying the rules of the FORWARD
chain. So, logging NAT connections (already made), shows that the
packets already have an output device. Example: "iptables -A FORWARD
-j LOG -o eth2", with example result:
Jul 6 10:18:29 thecrow IN=eth0 OUT=eth2 SRC=192.168.4.20
DST=62.57.136.215 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=46487 DF
PROTO=TCP SPT=33967 DPT=80 WINDOW=63712 RES=0x00 ACK URGP=0
3. The NAT applied by the connection tracker (not by 'nat' table) is
done _after_ the FORWARD chain of the filter table. I SNAT all
starting connections packets (table nat, chain POSTROUTING) to
192.168.16.1/24 or 192.168.17.1/24, and you may see in the last
example that the source address still is that of the LAN
(192.168.4.4/20).
4. I can say the same as in the third point about the chain FORWARD of
the 'mangle' table.
So.... I don't know how people do "multihop routing + NAT" without
Julian's patches. It's obvious that:
1. The connection tracker doesn't keep information about the devices
involved in the connection.
2. The routing policy database is asked BEFORE the FORWARD or
POSTROUTING chains. In fact, that's why the 'nat'/POSTROUTING chains
know to which IP change the source address (that is, according to the
selected output device by, for instance, the 'equalize' of a multihop
route).
May someone clarify, how people do that kind of multihop routing + NAT
without any patch? I've read that some people does that. IMO, those
configurations don't work fine. Can someone suggest any patch, in
order to get routing _after_ the connection tracking NAT is made?
Am I wrong in something?
Thanks in advance!
next reply other threads:[~2005-07-06 8:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-06 8:57 Lluís Batlle [this message]
2005-07-06 8:57 ` About routing, nat, the FORWARD chain, and a bit of Julian's patches Lluís Batlle
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=45219fb005070601577205f256@mail.gmail.com \
--to=viriketo@gmail.com \
--cc=lartc@mailman.ds9a.nl \
--cc=netfilter@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.