* ip_conntrack_ftp problem
@ 2003-03-28 7:40 Budai Laszlo
2003-03-28 8:27 ` Vincent Lim
2003-03-28 8:50 ` Michael K
0 siblings, 2 replies; 13+ messages in thread
From: Budai Laszlo @ 2003-03-28 7:40 UTC (permalink / raw)
To: netfilter
we use Redhat Linux 8 to connect our lan to the internet. Internally we
are using private addresses which are SNAT-ed (MASQUERADE) by the linux box.
We set up a firewall which in the forward chain looks like:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED
ACCEPT tcp -- 192.168.101.25 anywhere tcp dpt:telnet
ACCEPT tcp -- 192.168.101.24 anywhere tcp dpt:telnet
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ldap
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:imap
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:rtsp
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:cvspserver
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:cvspserver
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:5190
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:squid
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:https
ACCEPT udp -- 192.168.101.0/24 anywhere udp dpt:domain
ACCEPT udp -- 192.168.101.0/24 anywhere udp dpt:7070
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:7070
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:https
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:5050
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:pop3
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:http
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:domain
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:smtp
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ssh
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp
ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp-data
DROP tcp -- 192.168.101.0/24 anywhere
so we try to limit the access just to a few accepted services. We are
loading the ip_conntrack_ftp and ip_nat_ftp modules:
# lsmod
Module Size Used by Not tainted
ipt_state 1080 1 (autoclean)
cls_u32 6332 2 (autoclean)
sch_cbq 14912 2 (autoclean)
ip_nat_ftp 4240 0 (unused)
ip_conntrack_ftp 5088 0 (unused)
eepro100 22264 1
8139too 17736 1
mii 2156 0 [8139too]
iptable_mangle 2776 1 (autoclean)
ipt_MASQUERADE 2200 0 (autoclean)
ipt_REDIRECT 1368 3 (autoclean)
iptable_nat 19960 2 (autoclean) [ip_nat_ftp ipt_MASQUERADE ipt_REDIRECT]
ip_conntrack 21244 3 (autoclean) [ipt_state ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE ipt_REDIRECT iptable_nat]
iptable_filter 2412 1 (autoclean)
ip_tables 15224 8 [ipt_state iptable_mangle ipt_MASQUERADE ipt_REDIRECT iptable_nat iptable_filter]
mousedev 5524 0 (unused)
keybdev 2976 0 (unused)
hid 22244 0 (unused)
input 5920 0 [mousedev keybdev hid]
usb-uhci 26188 0 (unused)
usbcore 77024 1 [hid usb-uhci]
ext3 70336 3
jbd 52212 3 [ext3]
sym53c8xx 68240 4
sd_mod 13552 8
scsi_mod 107176 2 [sym53c8xx sd_mod]
but ftp trough the firewall still does not work. :(
what is wrong?
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 7:40 ip_conntrack_ftp problem Budai Laszlo
@ 2003-03-28 8:27 ` Vincent Lim
2003-03-28 9:43 ` Budai Laszlo
2003-03-28 8:50 ` Michael K
1 sibling, 1 reply; 13+ messages in thread
From: Vincent Lim @ 2003-03-28 8:27 UTC (permalink / raw)
To: Budai Laszlo; +Cc: netfilter
On Fri, 2003-03-28 at 15:40, Budai Laszlo wrote:
> Chain FORWARD (policy ACCEPT)
<snipped the rest>
> ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp
> ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp-data
> DROP tcp -- 192.168.101.0/24 anywhere
<snipped more>
> but ftp trough the firewall still does not work. :(
> what is wrong?
I would think that the replying packets can't get back.
Try putting a:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
--
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 8:27 ` Vincent Lim
@ 2003-03-28 9:43 ` Budai Laszlo
2003-03-28 10:19 ` Vincent Lim
0 siblings, 1 reply; 13+ messages in thread
From: Budai Laszlo @ 2003-03-28 9:43 UTC (permalink / raw)
To: Vincent Lim, netfilter
Thanks, this solved my problem. However, if you check my first post you
can see thet in the FORWARD chain I had :
ACCEPT all -- anywhere anywhere state RELATED
but seems it was not enough ... :( and I don't understand. isn't your
rule more restrictiv (state RELATED, ESTABILISHED) than my old rule
(just related)?
Thanks again,
Laszlo
Vincent Lim wrote:
>On Fri, 2003-03-28 at 15:40, Budai Laszlo wrote:
>
>
>
>>Chain FORWARD (policy ACCEPT)
>>
>>
>
><snipped the rest>
>
>
>
>>ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp
>>ACCEPT tcp -- 192.168.101.0/24 anywhere tcp dpt:ftp-data
>>DROP tcp -- 192.168.101.0/24 anywhere
>>
>>
>
><snipped more>
>
>
>
>>but ftp trough the firewall still does not work. :(
>>what is wrong?
>>
>>
>
>I would think that the replying packets can't get back.
>Try putting a:
>iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 9:43 ` Budai Laszlo
@ 2003-03-28 10:19 ` Vincent Lim
2003-03-28 10:43 ` Cedric Blancher
0 siblings, 1 reply; 13+ messages in thread
From: Vincent Lim @ 2003-03-28 10:19 UTC (permalink / raw)
To: Budai Laszlo; +Cc: netfilter
On Fri, 2003-03-28 at 17:43, Budai Laszlo wrote:
> Thanks, this solved my problem. However, if you check my first post you
> can see thet in the FORWARD chain I had :
>
> ACCEPT all -- anywhere anywhere state RELATED
>
> but seems it was not enough ... :( and I don't understand. isn't your
> rule more restrictiv (state RELATED, ESTABILISHED) than my old rule
> (just related)?
RELATED is for the ftp-data connection that is established after initial
connection attempt.
ESTABLISHED is for the original replies, which I think the server would
first used until a second/other connection is negotiated.
My $0.02
--
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 10:19 ` Vincent Lim
@ 2003-03-28 10:43 ` Cedric Blancher
2003-03-28 10:59 ` Vincent Lim
2003-03-28 12:17 ` Jozsef Kadlecsik
0 siblings, 2 replies; 13+ messages in thread
From: Cedric Blancher @ 2003-03-28 10:43 UTC (permalink / raw)
To: Vincent Lim; +Cc: Budai Laszlo, netfilter
Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> RELATED is for the ftp-data connection that is established after initial
> connection attempt.
To be precise, RELATED is only for the packet that initiates ftp-data
connection. Following ones will be ESTABLISHED.
A RELATED packet is similar to a NEW one, except that conntrack was
waiting for him.
--
Cédric Blancher <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 10:43 ` Cedric Blancher
@ 2003-03-28 10:59 ` Vincent Lim
2003-03-28 17:06 ` Cedric Blancher
2003-03-28 12:17 ` Jozsef Kadlecsik
1 sibling, 1 reply; 13+ messages in thread
From: Vincent Lim @ 2003-03-28 10:59 UTC (permalink / raw)
To: Cedric Blancher; +Cc: Budai Laszlo, netfilter
On Fri, 2003-03-28 at 18:43, Cedric Blancher wrote:
> Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> > RELATED is for the ftp-data connection that is established after initial
> > connection attempt.
>
> To be precise, RELATED is only for the packet that initiates ftp-data
> connection. Following ones will be ESTABLISHED.
>
> A RELATED packet is similar to a NEW one, except that conntrack was
> waiting for him.
The below excerpt is taken from this url:
http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial
/iptables-tutorial.html#STATEMACHINE
(url is wrapped)
RELATED
<snipped beginning>
..that it is RELATED. Some good examples of connections that can be
considered as RELATED are the FTP-data connections that are considered
RELATED to the FTP control port, and the DCC connections issued through
IRC. This could be used to allow ICMP replies, FTP transfers and DCC's
to work properly through the firewall. Do note that most TCP protocols
and some UDP protocols that rely on this mechanism are quite complex and
send connection information within the payload of the TCP or UDP data
segments, and hence require special helper modules to be correctly
understood.
So, initially..the replying packets need to match the ESTABLISHED?
(I'm asking this because Budai's initial rules only had RELATED and his
ftp wasn't working)
Then after establishing the RELATED ftp-data, subsequent packets match
the ESTABLISHED again?
--
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 10:59 ` Vincent Lim
@ 2003-03-28 17:06 ` Cedric Blancher
0 siblings, 0 replies; 13+ messages in thread
From: Cedric Blancher @ 2003-03-28 17:06 UTC (permalink / raw)
To: Vincent Lim; +Cc: Budai Laszlo, netfilter
Le ven 28/03/2003 à 11:59, Vincent Lim a écrit :
> So, initially..the replying packets need to match the ESTABLISHED?
> (I'm asking this because Budai's initial rules only had RELATED and his
> ftp wasn't working)
> Then after establishing the RELATED ftp-data, subsequent packets match
> the ESTABLISHED again?
You have two connections :
ftp
ftp-data
First ftp connection packet is NEW, others are ESTABLISHED. Then, a
ftp-data connection is built. First ftp-data connection packet is
RELATED, others are ESTABLISHED.
Problem with Budai's ruleset is that it does not accept ESTABLISHED
packet in FORWARD chain, as you told him at first with the rule that
fixes the issue.
--
Cédric Blancher <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 10:43 ` Cedric Blancher
2003-03-28 10:59 ` Vincent Lim
@ 2003-03-28 12:17 ` Jozsef Kadlecsik
2003-03-28 12:46 ` Cedric Blancher
1 sibling, 1 reply; 13+ messages in thread
From: Jozsef Kadlecsik @ 2003-03-28 12:17 UTC (permalink / raw)
To: Cedric Blancher; +Cc: Vincent Lim, Budai Laszlo, netfilter
On 28 Mar 2003, Cedric Blancher wrote:
> Le ven 28/03/2003 à 11:19, Vincent Lim a écrit :
> > RELATED is for the ftp-data connection that is established after initial
> > connection attempt.
>
> To be precise, RELATED is only for the packet that initiates ftp-data
> connection. Following ones will be ESTABLISHED.
>
> A RELATED packet is similar to a NEW one, except that conntrack was
> waiting for him.
No, that's not true. Every packet handled by the helpers are RELATED.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: ip_conntrack_ftp problem
2003-03-28 12:17 ` Jozsef Kadlecsik
@ 2003-03-28 12:46 ` Cedric Blancher
2003-03-28 14:10 ` Jozsef Kadlecsik
0 siblings, 1 reply; 13+ messages in thread
From: Cedric Blancher @ 2003-03-28 12:46 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Vincent Lim, Budai Laszlo, netfilter
Le ven 28/03/2003 à 13:17, Jozsef Kadlecsik a écrit :
> On 28 Mar 2003, Cedric Blancher wrote:
> > A RELATED packet is similar to a NEW one, except that conntrack was
> > waiting for him.
> No, that's not true. Every packet handled by the helpers are RELATED.
I may be wrong, but that's not what my experience says :
root@elendil:~# iptables --version
iptables v1.2.7a
root@elendil:~# iptables -F INPUT
root@elendil:~# iptables -A INPUT -m helper --helper ftp -m state --state RELATED -j LOG --log-prefix 'RELATED_FTP '
root@elendil:~# iptables -A INPUT -m helper --helper ftp -m state --state ESTABLISHED -j LOG --log-prefix 'ESTABLISHED_FTP '
root@elendil:~# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
LOG all -- anywhere anywhere helper match "ftp" state RELATED LOG level warning prefix `RELATED_FTP '
LOG all -- anywhere anywhere helper match "ftp" state ESTABLISHED LOG level warning prefix `ESTABLISHED_FTP '
Then I open a FTP connection, grabbing a file list via ls using active
FTP so I can see RELATED ftp-data opening :
root@elendil:~# tail -f /var/log/messages
[...]
Mar 28 13:38:50 elendil kernel: RELATED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2955 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2956 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=2957 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=2958 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=569 TOS=0x00 PREC=0x00 TTL=64 ID=2959 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK PSH FIN URGP=0
Mar 28 13:38:50 elendil kernel: ESTABLISHED_FTP IN=eth0 OUT= MAC=xx SRC=192.168.1.4 DST=192.168.1.3 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=2960 DF PROTO=TCP SPT=20 DPT=34777 WINDOW=5840 RES=0x00 ACK URGP=0
[...]
(stripped MAC stuff for convenience)
I can see RELATED packet from server:20 to my station:34770 (first
line). Following packets (line 2, 4, 5 and 6) for this connection are
ESTABLISHED. So, the way I understand this behaviour, is that a RELATED
packet is like a NEW one, but has an expectation on which it will be
matched.
I built iptables with POM from CVS.
--
Cédric Blancher <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
2003-03-28 12:46 ` Cedric Blancher
@ 2003-03-28 14:10 ` Jozsef Kadlecsik
0 siblings, 0 replies; 13+ messages in thread
From: Jozsef Kadlecsik @ 2003-03-28 14:10 UTC (permalink / raw)
To: Cedric Blancher; +Cc: Vincent Lim, Budai Laszlo, netfilter
On 28 Mar 2003, Cedric Blancher wrote:
> Le ven 28/03/2003 à 13:17, Jozsef Kadlecsik a écrit :
> > On 28 Mar 2003, Cedric Blancher wrote:
> > > A RELATED packet is similar to a NEW one, except that conntrack was
> > > waiting for him.
> > No, that's not true. Every packet handled by the helpers are RELATED.
>
> I may be wrong, but that's not what my experience says :
No, you are correct. My stupidity goes to infinity. Sorry.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: ip_conntrack_ftp problem
2003-03-28 7:40 ip_conntrack_ftp problem Budai Laszlo
2003-03-28 8:27 ` Vincent Lim
@ 2003-03-28 8:50 ` Michael K
1 sibling, 0 replies; 13+ messages in thread
From: Michael K @ 2003-03-28 8:50 UTC (permalink / raw)
To: 'Budai Laszlo', netfilter
> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Budai Laszlo
> Sent: Friday, March 28, 2003 8:41 AM
> To: netfilter@lists.netfilter.org
> Subject: ip_conntrack_ftp problem
>
>
>
>
> we use Redhat Linux 8 to connect our lan to the internet.
> Internally we
> are using private addresses which are SNAT-ed (MASQUERADE) by
> the linux box.
>
> We set up a firewall which in the forward chain looks like:
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> ACCEPT all -- anywhere anywhere
> state RELATED
> ACCEPT tcp -- 192.168.101.25 anywhere
> tcp dpt:telnet
> ACCEPT tcp -- 192.168.101.24 anywhere
> tcp dpt:telnet
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:ldap
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:imap
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:rtsp
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:cvspserver
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:cvspserver
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:5190
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:squid
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:https
> ACCEPT udp -- 192.168.101.0/24 anywhere
> udp dpt:domain
> ACCEPT udp -- 192.168.101.0/24 anywhere
> udp dpt:7070
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:7070
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:https
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:5050
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:pop3
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:http
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:domain
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:smtp
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:ssh
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:ftp
> ACCEPT tcp -- 192.168.101.0/24 anywhere
> tcp dpt:ftp-data
> DROP tcp -- 192.168.101.0/24 anywhere
>
>
> so we try to limit the access just to a few accepted services. We are
> loading the ip_conntrack_ftp and ip_nat_ftp modules:
>
> # lsmod
> Module Size Used by Not tainted
> ipt_state 1080 1 (autoclean)
> cls_u32 6332 2 (autoclean)
> sch_cbq 14912 2 (autoclean)
> ip_nat_ftp 4240 0 (unused)
> ip_conntrack_ftp 5088 0 (unused)
> eepro100 22264 1
> 8139too 17736 1
> mii 2156 0 [8139too]
> iptable_mangle 2776 1 (autoclean)
> ipt_MASQUERADE 2200 0 (autoclean)
> ipt_REDIRECT 1368 3 (autoclean)
> iptable_nat 19960 2 (autoclean) [ip_nat_ftp
> ipt_MASQUERADE ipt_REDIRECT]
> ip_conntrack 21244 3 (autoclean) [ipt_state
> ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE ipt_REDIRECT iptable_nat]
> iptable_filter 2412 1 (autoclean)
> ip_tables 15224 8 [ipt_state iptable_mangle
> ipt_MASQUERADE ipt_REDIRECT iptable_nat iptable_filter]
> mousedev 5524 0 (unused)
> keybdev 2976 0 (unused)
> hid 22244 0 (unused)
> input 5920 0 [mousedev keybdev hid]
> usb-uhci 26188 0 (unused)
> usbcore 77024 1 [hid usb-uhci]
> ext3 70336 3
> jbd 52212 3 [ext3]
> sym53c8xx 68240 4
> sd_mod 13552 8
> scsi_mod 107176 2 [sym53c8xx sd_mod]
>
>
> but ftp trough the firewall still does not work. :(
> what is wrong?
>
> Thanks,
> Laszlo
>
I'm sure that active ftp works. Active FTP uses port TCP/20 for data
channel. Passive ftp uses > TCP/1023
So
Active FTP uses TCP port 21 and 20
Passive FTP uses TCP port 21 and > 1023
/Klintan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
@ 2003-03-28 12:44 blancher
0 siblings, 0 replies; 13+ messages in thread
From: blancher @ 2003-03-28 12:44 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ip_conntrack_ftp problem
@ 2003-03-28 12:45 blancher
0 siblings, 0 replies; 13+ messages in thread
From: blancher @ 2003-03-28 12:45 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-03-28 17:06 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-28 7:40 ip_conntrack_ftp problem Budai Laszlo
2003-03-28 8:27 ` Vincent Lim
2003-03-28 9:43 ` Budai Laszlo
2003-03-28 10:19 ` Vincent Lim
2003-03-28 10:43 ` Cedric Blancher
2003-03-28 10:59 ` Vincent Lim
2003-03-28 17:06 ` Cedric Blancher
2003-03-28 12:17 ` Jozsef Kadlecsik
2003-03-28 12:46 ` Cedric Blancher
2003-03-28 14:10 ` Jozsef Kadlecsik
2003-03-28 8:50 ` Michael K
-- strict thread matches above, loose matches on Subject: below --
2003-03-28 12:44 blancher
2003-03-28 12:45 blancher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox