iptables problem

iptables problem

[Ashley M. Kirchner]

    I have three machines on our private network that need unrestricted 
access to and from FTP.  These are little photo kiosks that periodically 
connect to the master service machine elsewhere through ftp to send 
files and then receives information back.

    The machine running iptables has eth0 with our public ip and eth2 
with the internal (192.168.x.x) ip (where the three machines are on.) 

    Help anyone?

Re: iptables problem

[Buddy wu]

what's your problem or what do you mean?

2005/11/2, Ashley M. Kirchner <ashley@pcraft.com>:
>
>     I have three machines on our private network that need unrestricted
> access to and from FTP.  These are little photo kiosks that periodically
> connect to the master service machine elsewhere through ftp to send
> files and then receives information back.
>
>     The machine running iptables has eth0 with our public ip and eth2
> with the internal (192.168.x.x) ip (where the three machines are on.)
>
>     Help anyone?
>
>
>

Re: Re: iptables problem

[Ashley M. Kirchner]

Buddy wu wrote:

>what's your problem or what do you mean?
>  
>
    Problem is that while they can connect OUT, nothing from the outside 
can connect to them.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem

[Buddy wu]

>     Problem is that while they can connect OUT, nothing from the outside
> can connect to them.

I think you should load the ip_nat_ftp and ip_conntrack_ftp moudles.
do you load them?

RE: Re: iptables problem

[Rob Sterenborg]

>> what's your problem or what do you mean?
>> 
>> 
>     Problem is that while they can connect OUT, nothing from
> the outside can connect to them.

If you don't let us know what you have already done, we don't know
what's wrong.


Gr,
Rob

Re: Re: iptables problem

[Nikolai Georgiev]

Ashley M. Kirchner wrote:

> Buddy wu wrote:
>
>> what's your problem or what do you mean?
>>  
>>
>    Problem is that while they can connect OUT, nothing from the
> outside can connect to them.
>
Hello there, i think this should do
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED -j
ACCEPT
iptables -A OUTPUT --src $YOUR_IP -m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT

Re: Re: iptables problem

[Rob Sterenborg]

On Wed, November 2, 2005 08:20, Nikolai Georgiev wrote:
>>    Problem is that while they can connect OUT, nothing from the
>> outside can connect to them.
>>
> Hello there, i think this should do
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -A INPUT --dst $YOUR_IP -m state --state ESTABLISHED,RELATED
> -j ACCEPT
> iptables -A OUTPUT --src $YOUR_IP -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT

The INPUT and OUTPUT chains are for local traffic.
These kiosk hosts are probably *behind* iptables, so traffic will
travel through the FORWARD chain.

If you need external connections forwarded to hosts behind the
firewall, you need DNAT rules to make it happen.

In this case, the OP has 3 hosts to wich he wants to connect ("nothing
from the outside can connect to them", outgoing connections are
already working).
FTP only uses port 21/tcp (and 20). It's to my knowledge not possible
to forward 1 port to 3 hosts simultaneously (if that would do any
good), so he'll need to assign different ports for the second and
third host.
Something like :
21/tcp -> host 1
41/tcp -> host 2
61/tcp -> host 3
(if these ports are free).


Gr,
Rob

Re: Re: iptables problem

[Ashley M. Kirchner]

Rob Sterenborg wrote:

>The INPUT and OUTPUT chains are for local traffic.
>These kiosk hosts are probably *behind* iptables, so traffic will
>travel through the FORWARD chain.
>
>If you need external connections forwarded to hosts behind the
>firewall, you need DNAT rules to make it happen.
>  
>
    Yes, the kiosks are behind the firewall (iptables) and need 
unrestricted access to and from the internet, but only for FTP.

>In this case, the OP has 3 hosts to wich he wants to connect ("nothing
>from the outside can connect to them", outgoing connections are
>already working).
>FTP only uses port 21/tcp (and 20). It's to my knowledge not possible
>to forward 1 port to 3 hosts simultaneously (if that would do any
>good), so he'll need to assign different ports for the second and
>third host.
>Something like :
>21/tcp -> host 1
>41/tcp -> host 2
>61/tcp -> host 3
>(if these ports are free).
>  
>
    All right, so this is what I currently have in my iptables rules:

-A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT --to-destination 
192.168.1.xxx
-A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT --to-destination 
192.168.1.xxx

    ...and further down:

-A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 21 
--tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp --dport 20 
--tcp-flags SYN,RST,ACK SYN -j ACCEPT


    In my logs, I see this:

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF 
PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF 
PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0 

kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx 
DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF 
PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0 


    The other problem is that, while I can change the FTP port on the 
kiosks, I can't change it on the other end (the receiving and sending) 
so I'm not sure how to handle that part.  They will always attempt to 
connect on the standard FTP port, which two of these machines won't be 
listening to since I would've changed them so they don't conflict with 
one another.  Or is that not so?


-- 
W | It's not a bug - it's an undocumented feature.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / Websmith             .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

RE: Re: iptables problem

[Rob Sterenborg]

>     Yes, the kiosks are behind the firewall (iptables) and need
> unrestricted access to and from the internet, but only for FTP.

...

>     All right, so this is what I currently have in my iptables rules:
> 
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT
> --to-destination 192.168.1.xxx
> -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT
> --to-destination 192.168.1.xxx
> 
>     ...and further down:
> 
> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
> --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
> --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT

I assume your FORWARD policy is DROP ?

If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20
is then RELATED to the connection. So, do you also have (something like)
:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

You *do* load the ftp conntack helpers, do you ?

>     In my logs, I see this:
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF
> PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF
> PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
> 
> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF
> PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

This looks like an ACK to me. Not sure why such packet would be in the
NEW state on port 21, where a ftp-client would connect to at first so I
would think it would be in the ESTABLISHED state. (Also not sure what
the logging rule looks like.)
Maybe someone else who has better knowledge of this can help here.

You could skip the tcp-flags at first and see if that works.

>     The other problem is that, while I can change the FTP port on the
> kiosks, I can't change it on the other end (the receiving and sending)
> so I'm not sure how to handle that part.  They will always attempt to
> connect on the standard FTP port, which two of these machines
> won't be listening to since I would've changed them so they don't
> conflict with one another.  Or is that not so?

You don't have to run the ftp service of the kiosk hosts on different
ports : just forward the external ports, let's say (40/)41 and (60/)61,
to ports (20/)21 on the kiosk hosts. But that is no solution to your
problem I suppose, because of the serverside problem.

Maybe you can let the kiosk hosts connect to the server and perform GET
and PUT commands. The server then only has to put the needed updates in
a specific directory where the kiosk hosts can download them from. This
way the hosts themselves don't have to be reachable on the internet
which would be better from a security point of view.


Gr,
Rob

Re: Re: iptables problem

[Ashley M. Kirchner]

>Maybe you can let the kiosk hosts connect to the server and perform GET
>and PUT commands. The server then only has to put the needed updates in
>a specific directory where the kiosk hosts can download them from. This
>way the hosts themselves don't have to be reachable on the internet
>which would be better from a security point of view.
>  
>
    Thanks for the explanation Rob.

    I can't control what happens on the serverside.  That's a third 
party company.  I figured regardless of me being able to forward port 21 
to one of these machines without a problem, I can't do it for all 
three.  So I think I'm screwed either way.  Grrr...

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Jim Laurino]

On 2005.11.03 01:45, Ashley M. Kirchner - ashley@pcraft.com wrote:
> 
>> Maybe you can let the kiosk hosts connect to the server and perform GET
>> and PUT commands. The server then only has to put the needed updates in
>> a specific directory where the kiosk hosts can download them from. This
>> way the hosts themselves don't have to be reachable on the internet
>> which would be better from a security point of view.
>>
>    Thanks for the explanation Rob.
> 
>    I can't control what happens on the serverside.  That's a third party  
> company.  I figured regardless of me being able to forward port 21 to one of  
> these machines without a problem, I can't do it for all three.  So I think  
> I'm screwed either way.  Grrr...

OK, here is how I understand your situation:
Each kiosk must have a distinct identity to the outside service.
A kiosk must play the role of an ftp server.
A server has to listen on a well known port.
The outside system can only use the standard ftp port.
(This does seem a rather inflexible design, but ...)
The only other way to distinguish servers is the IP address.

So, maybe you can get more IP addresses.

Some ISP's allow you to have more than one public IP.
(Sometimes they want a few bucks extra rent :-)

You can arrange to have the firewall in question
respond to 3 IP addresses on the outside interface and
forward the now distinct traffic to the 3 kiosks.
If this is possible, it might be better than being screwed.

HTH

-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> You can arrange to have the firewall in question
> respond to 3 IP addresses on the outside interface and
> forward the now distinct traffic to the 3 kiosks.
> If this is possible, it might be better than being screwed.

    That would be nice, but no can do.  Remember, the server end, or 
receiving end, is a third party company.  They have hundreds, if not 
thousands of these little kiosks scattered across the country.  We are 
but a tiny little company with three of those kiosks.  Each kiosk makes 
an outbound FTP connection to the server.  Then the server makes an 
inbound connection back to the kiosk.  This is where it fails because it 
doesn't know where it came from since the kiosks are behind the firewall.

    Putting the kiosks OUTSIDE the firewall (with different IPs) also 
won't work because they also need to communicate (via windows shares) to 
internal machines, again, same scenario...they contact a print station, 
and the print station contacts them.  So you see, being screwed is the 
only option I see here.  Unless I'm overlooking something.

    And I can't tell the other company to send data to separate IPs 
either because their system works based on the packet they first receive 
when the kiosk contacts them.  Which goes back to my point above (about 
putting the kiosks outside the firewall.)

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive sender for this address)

[Sven Schuster]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]


Hi Ashley,

On Thu, Nov 03, 2005 at 09:02:58AM -0700, Ashley M. Kirchner told us:
>    And I can't tell the other company to send data to separate IPs 
> either because their system works based on the packet they first receive 
> when the kiosk contacts them.  Which goes back to my point above (about 
> putting the kiosks outside the firewall.)

you say "their" system works based on the packet they first receive
when contacting them. So with multiple IPs, wouldn't it work to let
each kiosk contact the server via its own IP address via SNAT??
E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the public
ip 5.6.7.8, so when it contacts the server it will establish a
connection back to 5.6.7.8 which will in turn be DNATted to 1.2.3.4.
kiosk 2 (1.2.3.5) --> 5.6.7.9
and so on...
I haven't read the whole thread, so it might be that I missed
something :-)

Wouldn't this work??


HTH

Sven

-- 
Linux zion.homelinux.com 2.6.14-rc5-mm1_14 #14 Wed Nov 2 11:36:18 CET 2005 i686 athlon i386 GNU/Linux
 17:19:16 up 1 day,  5:25,  2 users,  load average: 0.38, 0.18, 0.07

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)

[Jim Laurino]

On 2005.11.03 11:02, Ashley M. Kirchner - ashley@pcraft.com wrote:
> Jim Laurino wrote:
> 
>> You can arrange to have the firewall in question
>> respond to 3 IP addresses on the outside interface and
>> forward the now distinct traffic to the 3 kiosks.
>> If this is possible, it might be better than being screwed.
> 
>    That would be nice, but no can do.  Remember, the server end, or  
> receiving end, is a third party company.  They have hundreds, if not  
> thousands of these little kiosks scattered across the country.  We are but a  
> tiny little company with three of those kiosks.  Each kiosk makes an  
> outbound FTP connection to the server.  Then the server makes an inbound  
> connection back to the kiosk.  This is where it fails because it doesn't  
> know where it came from since the kiosks are behind the firewall.

Perhaps I am confused,
I thought that the kiosks in question were acting as ftp servers.

If the kiosks are ftp clients, the situation is entirely different.
This should not be a problem.

> 
>    Putting the kiosks OUTSIDE the firewall (with different IPs) also won't  
> work because they also need to communicate (via windows shares) to internal  
> machines, again, same scenario...they contact a print station, and the print  
> station contacts them.

Exactly what do you mean when you say "contacts".
Do you mean that the kiosk also must act as an ftp server?
Or do you mean contact as in a passive ftp transfer?
Passive ftp you can support via ftp helpers and RELATED.

> So you see, being screwed is the only option I see
> here.  Unless I'm overlooking something.
> 
>    And I can't tell the other company to send data to separate IPs either  
> because their system works based on the packet they first receive when the  
> kiosk contacts them.  Which goes back to my point above (about putting the  
> kiosks outside the firewall.)
> 
>-- 
> H | I haven't lost my mind; it's backed up on tape somewhere.
>  +--------------------------------------------------------------------
>  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
>  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
>  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
>  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.
> 
> 
> 
>
-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

RE: Re: iptables problem (nfcan: addressed to exclusivesender for this address)

[Rob Sterenborg]

> you say "their" system works based on the packet they first
> receive when contacting them. So with multiple IPs, wouldn't
> it work to let each kiosk contact the server via its own IP
> address via SNAT??
> E.g. kiosk 1 which is internally 1.2.3.4 gets natted to the
> public ip 5.6.7.8, so when it contacts the server it will
> establish a connection back to 5.6.7.8 which will in turn be
> DNATted to 1.2.3.4.
> kiosk 2 (1.2.3.5) --> 5.6.7.9
> and so on...

Yes this could work. Stupid I didn't think of it.

Ext_ip1 -(DNAT)-> Int_ip1
Ext_ip2 -(DNAT)-> Int_ip2
Ext_ip3 -(DNAT)-> Int_ip3

But then (reading OP's other post : "And I can't tell the other company
to send data to separate IPs either because their system works based on
the packet they first receive when the kiosk contacts them") you should
also SNAT to different externals IP's :

Int_ip1 -(SNAT)-> Ext_ip1
Int_ip2 -(SNAT)-> Ext_ip2
Int_ip3 -(SNAT)-> Ext_ip3

> I haven't read the whole thread, so it might be that I missed
> something :-) 

I think not ;^)


Gr,
Rob

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> If the kiosks are ftp clients, the situation is entirely different.
> This should not be a problem.

    They are clients.  But...keep reading...  Something changed today.

> Exactly what do you mean when you say "contacts".
> Do you mean that the kiosk also must act as an ftp server?
> Or do you mean contact as in a passive ftp transfer?
> Passive ftp you can support via ftp helpers and RELATED.

    Neither.  It's through windows network shares.  The kiosk puts the 
order on it's local drive which is shared to the network, and the print 
station comes and fetches the info periodically.  Keep reading...


    I just got off the phone with the company and they made a small 
change in our config.  Now, all the kiosks have to do is connect via FTP 
to their server and drop a file.  That's it.  Nothing comes back, no 
inbound connections to the kiosks.  Just going out.

    So, just out of curiosity, I decided to try doing a manual FTP 
transfer from a completely different machine on the network.  One that 
CAN connect to external ftp sites just fine and transfer files.  And 
this is what I see:

    - Open DOS window
    - Connect to FTP server
    - enter 'PUT file.xml' command
    ...and that's where it hangs.

    Now, looking in the firewall logs, I see this:

Nov  3 13:47:19 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 
ID=43803 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=65420 RES=0x00 ACK PSH URGP=0

Nov  3 13:47:49 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=40 TOS=0x00 PREC=0x00 TTL=127 
ID=43949 DF PROTO=TCP SPT=4100 DPT=21 WINDOW=0 RES=0x00 ACK RST URGP=0

Nov  3 13:47:55 serpico kernel: New not syn:IN=eth2 OUT=eth0 
SRC=192.168.1.253 DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 
ID=43987 DF PROTO=TCP SPT=4117 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0

    In my DOS window, I see this (while those errors are popping up in 
syslog):

    ftp> put 2008701033.xml
            ... pause ... first error in syslog
            ... pause ... second line in syslog
    Connection closed by remote host.
            ... third line in syslog
    ftp>
   

    Please remember that this is a machine onto which I CAN open an ftp 
connection to anywhere in the world and be able to send and receive 
files just fine.  So then why is it not working when going to these people?

    ---- FIVE MINUTES LATER ----

    I just tried directly from the firewall machine and found out they 
don't allow PASSIVE mode ON... As soon as I turn passive mode off, the 
transfer, FROM THE FIREWALL MACHINE, works.  (firewall machine has an 
external IP)

    So now I wonder, is it because of the passive mode setting they 
have?  Could that be why ftp transfers from within the firewall fails?

-- 
W | It's not a bug - it's an undocumented feature.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / Websmith             .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

RE: Re: iptables problem

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




Why not have one system that reaches out for the files, and brings them 
inside, then point the kiosks at that one system?  Far easier to maintain 
and troubleshoot and far less FW coding.


Thanks,

Ron DuFresne


On Thu, 3 Nov 2005, Rob Sterenborg wrote:

>>     Yes, the kiosks are behind the firewall (iptables) and need
>> unrestricted access to and from the internet, but only for FTP.
>
> ...
>
>>     All right, so this is what I currently have in my iptables rules:
>>
>> -A PREROUTING -i eth0 -p tcp -m tcp --dport 21 -j DNAT
>> --to-destination 192.168.1.xxx
>> -A PREROUTING -i eth0 -p tcp -m tcp --dport 20 -j DNAT
>> --to-destination 192.168.1.xxx
>>
>>     ...and further down:
>>
>> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
>> --dport 21 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
>> -A FORWARD -i eth0 -o eth2 -p tcp -m state --state NEW -m tcp
>> --dport 20 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
>
> I assume your FORWARD policy is DROP ?
>
> If you use RELATED,ESTABLISHED, you only need to allow port 21. Port 20
> is then RELATED to the connection. So, do you also have (something like)
> :
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> You *do* load the ftp conntack helpers, do you ?
>
>>     In my logs, I see this:
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1587 DF
>> PROTO=TCP SPT=1186 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1588 DF
>> PROTO=TCP SPT=1181 DPT=21 WINDOW=65196 RES=0x00 ACK PSH URGP=0
>>
>> kernel: New not syn:IN=eth2 OUT=eth0 SRC=192.168.1.xxx
>> DST=206.112.90.196 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=1589 DF
>> PROTO=TCP SPT=1184 DPT=21 WINDOW=65338 RES=0x00 ACK PSH URGP=0
>
> This looks like an ACK to me. Not sure why such packet would be in the
> NEW state on port 21, where a ftp-client would connect to at first so I
> would think it would be in the ESTABLISHED state. (Also not sure what
> the logging rule looks like.)
> Maybe someone else who has better knowledge of this can help here.
>
> You could skip the tcp-flags at first and see if that works.
>
>>     The other problem is that, while I can change the FTP port on the
>> kiosks, I can't change it on the other end (the receiving and sending)
>> so I'm not sure how to handle that part.  They will always attempt to
>> connect on the standard FTP port, which two of these machines
>> won't be listening to since I would've changed them so they don't
>> conflict with one another.  Or is that not so?
>
> You don't have to run the ftp service of the kiosk hosts on different
> ports : just forward the external ports, let's say (40/)41 and (60/)61,
> to ports (20/)21 on the kiosk hosts. But that is no solution to your
> problem I suppose, because of the serverside problem.
>
> Maybe you can let the kiosk hosts connect to the server and perform GET
> and PUT commands. The server then only has to put the needed updates in
> a specific directory where the kiosk hosts can download them from. This
> way the hosts themselves don't have to be reachable on the internet
> which would be better from a security point of view.
>
>
> Gr,
> Rob
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDaob8st+vzJSwZikRAqYCAKDUUlIYj/Kc10C/NxsnEpRxRb4jjQCfTBU3
RYixAO5DstCZTr9QMCqXygI=
=hj6F
-----END PGP SIGNATURE-----

Re: Re: iptables problem

[Ashley M. Kirchner]

R. DuFresne wrote:

> Why not have one system that reaches out for the files, and brings 
> them inside, then point the kiosks at that one system?  Far easier to 
> maintain and troubleshoot and far less FW coding.

    Because I didn't code these machines.  They are proprietary and 
third party to us.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 3 Nov 2005, Ashley M. Kirchner wrote:

> R. DuFresne wrote:
>
>> Why not have one system that reaches out for the files, and brings them 
>> inside, then point the kiosks at that one system?  Far easier to maintain 
>> and troubleshoot and far less FW coding.
>
>   Because I didn't code these machines.  They are proprietary and third 
> party to us.
>
>

Interesting, and that means I suspect that you have no ability to tune or 
config them as well?  Could one put in a request the third parties config 
them to look at one trusted host you could setup to pull the files from?

Have they been "tested" for their security?  Seems a tad risky, depending 
upon placement, hopefully they are in a dmz and not the soft chewy 
center....

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDatL0st+vzJSwZikRArWLAKDA/urNj4sEruwm7KU8ezInKPLpJQCeJk+R
MFr5oi+c3stQZx0mqQJgqmE=
=Z32v
-----END PGP SIGNATURE-----

Re: Re: iptables problem

[Ashley M. Kirchner]

R. DuFresne wrote:

> Interesting, and that means I suspect that you have no ability to tune 
> or config them as well?  Could one put in a request the third parties 
> config them to look at one trusted host you could setup to pull the 
> files from?
>
> Have they been "tested" for their security?  Seems a tad risky, 
> depending upon placement, hopefully they are in a dmz and not the soft 
> chewy center....

    Tested for security?  Does the fact that they transmit order details 
(including plain text client information and an encrypted CC string 
within the same file) via plain old FTP tell you anything?  Do I, 
personally, trust this system?  Oh HELL NO.  Would I, personally, use 
them to place any orders?  Oh HELL NO.  Do I have a choice in not using 
them?  Nope.  I'm merely the one that has to make them work...the big 
guys paid the money.

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Jim Laurino]

On 2005.11.03 14:57, Ashley M. Kirchner - ashley@pcraft.com wrote:
> Jim Laurino wrote:
>
...
>    I just got off the phone with the company and they made a small change in  
> our config.  Now, all the kiosks have to do is connect via FTP to their  
> server and drop a file.  That's it.  Nothing comes back, no inbound  
> connections to the kiosks.  Just going out.
> 
>    So, just out of curiosity, I decided to try doing a manual FTP transfer  
> from a completely different machine on the network.  One that CAN connect to  
> external ftp sites just fine and transfer files.  And this is what I see:
> 
>    - Open DOS window
>    - Connect to FTP server
>    - enter 'PUT file.xml' command
>    ...and that's where it hangs.
>
....
> 
>    Please remember that this is a machine onto which I CAN open an ftp  
> connection to anywhere in the world and be able to send and receive files  
> just fine.  So then why is it not working when going to these people?
> 
>    ---- FIVE MINUTES LATER ----
> 
>    I just tried directly from the firewall machine and found out they don't  
> allow PASSIVE mode ON... As soon as I turn passive mode off, the transfer,  
> FROM THE FIREWALL MACHINE, works.  (firewall machine has an external IP)
> 
>    So now I wonder, is it because of the passive mode setting they have?   
> Could that be why ftp transfers from within the firewall fails?
>

non-passive (active) FTP requires that
the outside ftp server be able to open
a secondary connection to the client.
That is why passive mode is so popular
when the ftp client is behind a firewall -
both of the connections are originated from the client,
and no ports have to be opened on the firewall
for the incoming secondary connection.

I was confused about this earlier,
and may have contributed to the confusion.

A clear explanation is here http://slacksite.com/other/ftp.html

So, it is possible that your firewall is not configured to allow
active mode ftp connections. (But it can be done).

HTH

-- 
Jim Laurino
nfcan.x.jimlaur@dfgh.net
Please reply to the list.
Only mail from the listserver reaches this address.

Re: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Ashley M. Kirchner]

Jim Laurino wrote:

> So, it is possible that your firewall is not configured to allow
> active mode ftp connections. (But it can be done).

    Okay, so what am I supposed to do to "fix" this?  Thanks for the 
link by the way.  Helped clear up some things...

-- 
H | I haven't lost my mind; it's backed up on tape somewhere.
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:ashley@pcraft.com>   .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith             .     800.441.3873 x130
  Photo Craft Imaging                       .     3550 Arapahoe Ave. #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A. 

RE: Re: iptables problem (nfcan: addressed to exclusive (nfcan: addressed to exclusive sender for this address) (nfcan: addressed to exclusive sender for this address) sender for this address)

[Rob Sterenborg]

>> So, it is possible that your firewall is not configured to allow
>> active mode ftp connections. (But it can be done).
> 
>     Okay, so what am I supposed to do to "fix" this?  Thanks for the

Check out section "Connection tracking and ftp" on this page :
http://kalamazoolinux.org/presentations/20010417/conntrack.html


Gr,
Rob