Такие дела:
есть три сетевых интерфейса: 172.24.х.х, 192.168.1.х и 192.168.200.х.
На 192.168.200.х приходит интернет, который нужно раздать на 192.168.1.х. Поднимается NAT, интернет раздается, но при этом из 172.24.х.х  становится недоступен, остаются только стабильные хорошие пинги и nmap показывает открытые порты.
Из 192.168.1.х все работает прекрасно.

http://lmgtfy.com/       тут уже был, ничего толкового не нашел.

На Дебиан 4.0 это все работало без бубна.

покажи правило для НАТа, скорее всего там не указан интерфейс

#!/bin/sh
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -t nat -F PREROUTING
iptables -t nat -F POSTROUTING
iptables -t mangle -F
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
iptables --table nat --append POSTROUTING --source 192.168.0.0/24 --out-interface eth1 -j MASQUERADE

на eth1 приходит интернет
и еще... если писать iptables -t nat -A ....  вместо iptables --table nat --append то нат не поднимается

попробуй такое правило
iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth1 -j SNAT --to-source 192.168.200.xxx

Все рано сеть 172.24 отваливается.
Может ли быть такое, что дебиан считает сеть 172.24 "небезопасной" по сравнению с 192,168,1,0 и 192,168,200,0 и каким-то образом блокировать все входящие из нее крме пингов?

Quoted from revenger

Все рано сеть 172.24 отваливается.
Может ли быть такое, что дебиан считает сеть 172.24 "небезопасной" по сравнению с 192,168,1,0 и 192,168,200,0 и каким-то образом блокировать все входящие из нее крме пингов?

эта подсеть абсолютно такая же как и любая другая приватная

покажи лучше таблицу маршрутизации

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
172.24.0.0      172.24.0.1      255.255.0.0     UG    0      0        0 eth0
172.24.0.0      172.24.0.4      255.255.0.0     UG    0      0        0 eth0
172.24.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         192.168.200.1   0.0.0.0         UG    0      0        0 eth1

Дома тоже ставил роутер аналогично, только на 2 сетевых интерфейса (внешний 172.24.х.х и внутренний 10.0.0.х), снаружи не было доступа по ssh и ftp? а изнутри был.

Цитата

172.24.0.0      172.24.0.1      255.255.0.0     UG    0      0        0 eth0
172.24.0.0      172.24.0.4      255.255.0.0     UG    0      0        0 eth0
172.24.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0

маршруты в одну подсеть но тремя способами
в истновской сети более сложная маршрутизация

Ну судя по всему не в этом причина проблемы. Пинги - то ходят нормально.

Quoted from revenger

Ну судя по всему не в этом причина проблемы. Пинги - то ходят нормально.

скорее всего не в этом, но это не повод не исправлять ошибки

Quoted from sem

скорее всего не в этом, но это не повод не исправлять ошибки

Ну вот, значит надо разобраться с проблемой первым делом, а потом заняться ошибками.

Имеет ли отношение к проблеме то, что при коннекте, допустим, по SSh или FTP запрашивает пароль, после чего соединение виснет намертво (это при поднятом НАТе)

промониторь пакеты tcpdump'ом  в течении одной сесси-соединения и посмотри что происходит. и не забудь смоттреть по очереди на входящем и исходящем интерфейсе

Мониторю. Пока ничего интересного.
Вот что пишет nmap:

Starting Nmap 5.00 ( http://nmap.org ) at 2010-11-09 14:53 EET
Interesting ports on xxx.users.ictnet.dp.ua (172.24.xxx.xxx):
Not shown: 983 closed ports
PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   filtered smtp
53/tcp   open     domain
80/tcp   open     http
110/tcp  open     pop3
111/tcp  open     rpcbind
119/tcp  open     nntp
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
143/tcp  open     imap
445/tcp  filtered microsoft-ds
901/tcp  open     samba-swat
1723/tcp open     pptp
2049/tcp open     nfs
3128/tcp open     squid-http
5900/tcp open     vnc

А вот что получается с телнетом:


$ telnet 172.24.xx.xxx 5900
Trying 172.24.xx.xxx...
Connected to 172.24.xx.xxx.
Escape character is '^]'.

Дальше тишина.
В-общем со всем этим богатством кроме пингов больше ничего не работает.