From: "Nicolas Olivier" <nolivier@alphalink.fr>
To: netfilter@lists.netfilter.org
Subject: ip_conntrack_ftp
Date: Fri, 24 Jun 2005 10:01:42 +0200 [thread overview]
Message-ID: <42BBBDE6.9040108@alphalink.fr> (raw)
Hi,
I've got the following architecture:
customer-1 rt-1 rt-2
______ ______ 10.0.0.2/30 10.0.0.1/30 ______
| | | |__________________________________| |
| |172.16.0.2/30 172.16.0.1/30| |nas1 nas1 | |
| |___________/ ... /______________| | | |
| | whatever nas0 | |10.0.0.5/30 10.0.0.6/30| |
| | | |__________________________________| |
|______| |______|eth1 eth1 |______|
eth0 |
10.10.60.23/24|
|
So customer-1 is connected to to rt-1 over ATM via a br2684.
When nas0 is created, the following is done:
ifconfig nas0 172.16.0.1 netmask 255.255.255.252 broadcast 172.16.0.3
ip route add table 1 172.16.0.0/30 dev nas0 proto static scope link src 172.16.0.1
ip route del 172.16.0.0/30 dev nas0 proto kernel scope link src 172.16.0.1
ip rule add dev nas0 lookup 1
For nas1:
ifconfig nas1 10.0.0.2 netmask 255.255.255.252 broadcast 10.0.0.3
ip route add default via 10.0.0.1 dev nas1 table 1
ip route del 10.0.0.0/30 dev nas1 proto kernel scope link src 10.0.0.2
ip route add table 1 10.0.0.0/30 dev nas1 proto static scope link src 10.0.0.2
ip rule add dev nas1 lookup 1
ip route del local 10.0.0.2 dev nas1 proto kernel scope host src 10.0.0.2
ip neighbour add 10.0.0.2 lladdr `ifmacget nas1` nud permanent dev nas1
ifmacget is a small binary returning the MAC address of the interface.
Idea behind this is to isolate customers related interfaces from main routing table in their own routing table.
So traffic comes from customers, goes through rt-1 via their dedicated routing table. It can goes to other customers that are isolated in that routing
table or goes through rt-2 via nas1.
rt-2 does its own stuff, like QoS or whatever. The point is that Internet related traffic goes back from rt-2 to rt-1 via the sub 10.0.0.4/30, and
then goes out via eth0.
So everything works like a charm in this architecture, except conntrack on active ftp.
I'm on customer-1, running a ftp client (lftp was used for the test) to connect to 1.1.1.1. Logging is correct, but when sending command fails, and
the ftp client runs a timer to try again sendind the command. After this first attempt, conntrack table contains those entries:
tcp 6 115 TIME_WAIT src=10.0.0.2 dst=1.1.1.1 sport=35045 dport=21 src=1.1.1.1 dst=10.10.60.23 sport=21 dport=1024 [ASSURED] use=1 mark=0
tcp 6 115 TIME_WAIT src=172.16.0.2 dst=1.1.1.1 sport=35045 dport=21 src=1.1.1.1 dst=10.0.0.2 sport=21 dport=35045 [ASSURED] use=1 mark=0
Then, when the timer fired, the command runs well, and everything works perfect. Those are the entries just after, the connection and a ls:
tcp 6 431996 ESTABLISHED src=10.0.0.2 dst=1.1.1.1 sport=35047 dport=21 src=1.1.1.1 dst=10.10.60.23 sport=21 dport=1025 [ASSURED] use=1
mark=0
tcp 6 116 TIME_WAIT src=10.0.0.2 dst=1.1.1.1 sport=35048 dport=42135 src=1.1.1.1 dst=10.10.60.23 sport=42135 dport=1025 [ASSURED] use=1
mark=0
tcp 6 116 TIME_WAIT src=172.16.0.2 dst=1.1.1.1 sport=35048 dport=42135 src=1.1.1.1 dst=10.0.0.2 sport=42135 dport=35048 [ASSURED] use=1
mark=0
tcp 6 431996 ESTABLISHED src=172.16.0.2 dst=1.1.1.1 sport=35047 dport=21 src=1.1.1.1 dst=10.0.0.2 sport=21 dport=35047 [ASSURED] use=1
mark=0
tcp 6 86 TIME_WAIT src=10.0.0.2 dst=1.1.1.1 sport=35045 dport=21 src=1.1.1.1 dst=10.10.60.23 sport=21 dport=1024 [ASSURED] use=1 mark=0
tcp 6 86 TIME_WAIT src=172.16.0.2 dst=1.1.1.1 sport=35045 dport=21 src=1.1.1.1 dst=10.0.0.2 sport=21 dport=35045 [ASSURED] use=1 mark=0
For me, it seems that the problem is due to ftp connection coming on rt-1 twice, but as other traffic runs well I'm a bit lost and I haven't got
enough knowledge in netfilter to fix this.
Any help or advice would be greatly appreciated, and if I was not clear enough, don't hesitate.
Thanks in advance.
Nicolas Olivier
next reply other threads:[~2005-06-24 8:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-24 8:01 Nicolas Olivier [this message]
2005-06-24 8:10 ` ip_conntrack_ftp Nicolas Olivier
-- strict thread matches above, loose matches on Subject: below --
2003-10-13 21:22 ip_conntrack_ftp Britt Tabor
2003-10-14 16:08 ` ip_conntrack_ftp Eric Leblond
2002-10-07 12:09 ip_conntrack_ftp vlad f kropachew
2002-10-10 1:40 ` ip_conntrack_ftp Alistair Tonner
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=42BBBDE6.9040108@alphalink.fr \
--to=nolivier@alphalink.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox