» Firewall *nix: iptables, ipfw, pf etc...

askad
В таком виде работать не будет. И вот почему.
1. Самая главная ошибка. Вы не указали правила для исходящих пакетов. Или повторяющиеся правила - это простая ошибка?
2. Если TRUST_IP и SIP_IP это переменные, то надо писать $TRUST_IP и $SIP_IP.

P.S. А где правила для остальных портов (80, 443, 3306 и др.)?
Если что, то можно подключить модуль multiport и делать одно правило на несколько портов.
P.S. А вообще поднимите виртуалку и потренируйтесь на ней.

Цитата:

1. Самая главная ошибка. Вы не указали правила для исходящих пакетов. Или повторяющиеся правила - это простая ошибка?

Забыл добавить OUTPUT цепочки


Код: iptables -A ports -s TRUST_IP -p tcp --sport 22 -j ACCEPT

Цитата:

А как проверить, что в моей версии iptables есть расширение multiport?

В вашей версии есть точно.

Цитата:

поднял, тренируюсь, просто там не всё на 100% идентично описанной ситуации.

А кто вам мешает сделать один в один? Это же виртуалки...

Цитата:

А кто вам мешает сделать один в один? Это же виртуалки...

Времени и опыта. Этих двух гадов катастрофически не хватает.

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

askad
У меня есть непоняток, вы не забыли про RTP трафик?

Приветствую.
Имеется установленный Linux Mint 13 на VMWare. Сеть работает через NAT.
На хосте Win 7.
Подскажите пожалуйста как настроить iptables, чтобы весь трафик с гостевого Linux уходил на сокс5. Пробовал proxychains, tsocks, dante - не получается весь трафик пустить на сокс. К примеру браузер работает через proxychains, но другие необходимые мне приложения не работают.
В работе сетей не шарю. В поиске нашёл вот такое правило:
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 3128
но положительных результатов это не дало.

Цитата:

iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 3128

Что бы использовать такую конструкция socks сервер должен знать что трафик к нему идёт не сам, а принудительно. Короче должен быть запущен в transparent режиме.

Socks сервер там же, ведь, на Mint'е? proxychains должен вообще-то норм пахать, правда он только для tcp соединений.

всем привет.
юзал фс14, перешёл в связи с апгрейдом железа на фс16
на фс14 были настроены правила через cbqinit
всё работало. резало кому надо, как надо. перенёс конфиги на фс16, и началась свистопляска с шейперами.
например клиенту режет udp как положено, а вот тсп трафик опускает ниже плинтуса, на уровне диалапа. причём вроде начинает качать нормально, а потом ниже и ниже.
кучу ядер персобирал, ставил и снова собирал, тестил - везде картина одна.
бился я с cbqinit, плюнул на это дело, перерыл горе документашки, и решил руками создать скрипт через tc. сделал, всё вроде верно, но с другой стороны как то коряво работает.
может глянете, и найдёте ошибку. но для начала опишу что и как.

описание:
имеем внешний канал который поступает на свитч, далее по vlan136 опрокидывается на пс-рутер, так же на свитч поступает канал на внутрегородские ресурсы по vlan137
ещё на пс-рутере есть vlan100 (локалка тоже через свитч)
имеем на пс-рутере свой bgp и автономку для юзеров.
и напоследок имеем tun0 интерфейс (ovpn) для раздачи инета для себя любимого - с любой точки города.
задача:
имеем канал 4мбита.
надо ограничить скачивание клиенту1 на скорости 1280кбит, клиенту2 на скорости 1мбит, себя любимого на скорости 512кбит, оставшуюся скорость отдать остальным юзерам.
причем у клиента1 и 2 должен быть высокий приоритет, если они качают, что бы их полосой никто не мог воспользоваться, даже я.
но если клиент1 и/или 2 освобождают свои полосы, их канал отдавался остальным абонентам в пользование. как только они начинают качать, что бы у остальных канал отбирался в пользу клиента1 и 2.

tc qdisc del dev vlan100 root
tc qdisc del dev tun0 root

tc qdisc add dev vlan100 root handle 1:0 cbq bandwidth 1Gbit \
avpkt 10000 cell 8

tc qdisc add dev tun0 root handle 1:0 cbq bandwidth 1Gbit \
avpkt 10000 cell 8

tc class add dev vlan100 parent 1:0 classid 1:1 cbq bandwidth 1Gbit \
rate 4Mbit weight 0.4Mbit prio 8 allot 1514 cell 8 maxburst 20 \
avpkt 10000 bounded

tc class add dev tun0 parent 1:1 classid 1:2 cbq bandwidth 1Gbit \
rate 512Kbit weight 51Kbit prio 3 allot 1514 cell 8 maxburst 20 \
avpkt 10000 borrow sharing
tc class add dev vlan100 parent 1:1 classid 1:3 cbq bandwidth 1Gbit \
rate 1280Kbit weight 128Kbit prio 1 allot 1514 cell 8 maxburst 20 \
avpkt 10000 borrow sharing
tc class add dev vlan100 parent 1:1 classid 1:4 cbq bandwidth 1Gbit \
rate 1Mbit weight 0.1Mbit prio 2 allot 1514 cell 8 maxburst 20 \
avpkt 10000 borrow sharing
tc class add dev vlan100 parent 1:1 classid 1:5 cbq bandwidth 1Gbit \
rate 4Mbit weight 0.4Mbit prio 5 allot 1514 cell 8 maxburst 20 \
avpkt 10000 borrow sharing

tc qdisc add dev tun0 parent 1:2 handle 20: sfq perturb 10
tc qdisc add dev vlan100 parent 1:3 handle 30: sfq perturb 10
tc qdisc add dev vlan100 parent 1:4 handle 40: sfq perturb 10
tc qdisc add dev vlan100 parent 1:5 handle 50: sfq perturb 10

tc filter add dev tun0 parent 1:0 protocol ip prio 1 u32 match ip \
dst xxx.238.104.102 flowid 1:2
tc filter add dev vlan100 parent 1:0 prio 1 protocol ip u32 match ip \
dst xxx.238.104.62 flowid 1:3
tc filter add dev vlan100 parent 1:0 protocol ip prio 1 u32 match ip \
dst xxx.238.105.14 flowid 1:4
tc filter add dev vlan100 parent 1:0 protocol ip prio 1 u32 match ip \
dst xxx.238.105.0/24 flowid 1:5
tc filter add dev vlan100 parent 1:0 protocol ip prio 1 u32 match ip \
dst xxx.238.106.0/24 flowid 1:5
tc filter add dev vlan100 parent 1:0 protocol ip prio 1 u32 match ip \
dst xxx.238.107.0/24 flowid 1:5

что тут не так? как то всё равно коряво работает. сижу, смотрю трафик у абонента xxx.238.104.62 как шёл на максимальной возможной так и идёт, зато у абонентов с flowid 1:5 он срезается до неприличия.

Цитата:

Socks сервер там же, ведь, на Mint'е?

Сокс сервер находится за пределами Minta. К примеру сокс сервер может быть как вариант вообще не в моей сети. Возможно организовать перенаправление всего трафика с гостя Linux на сокс?
Мне нужно запустить некоторые приложения через wine и соединиться через сокс. Так вот именно proxychains не может этого сделать.

megasoup2009
Действие REDIRECT это только для локальных ухищрений, в случае удалённой машины вам нужно действие DNAT.
А вот что proxychains не может Вам помочь это странно. Воспроизводить ситуацию возможности сейчас нету...

Так получилось, что создал отдельную тему , хотя логичнее было написать тут, если кто может помочь - посмотрите пожалуйста этот топ : Ссылка

Всем привет
Нужен совет с пробросом портов.
Система ФриБСД 8. Нужно пробросить опредёные порты, ну там радмин, рдп и т.д. на другие машины.
В общем сделал так: в "/etc/rc.d" создал исполняемый файл с содержанием natd -n re1 -f '/etc/natd.conf' файл /etc/natd.conf прописал
use_sockets yes
same_ports yes
unregistered_only yes
redirect_port tcp 192.168.0.1:3389 3389
в ипфв доступ открыт, в диспетчере демон висит, пробывал убивать и подгружать заново, не работает.
re1 - внешний интерфейс
Подскажите пожалуйста.

Цитата:

Так получилось, что создал отдельную тему , хотя логичнее было написать тут, если кто может помочь - посмотрите пожалуйста этот топ : Ссылка

Eluvatar а как провайдеры отнеслись к тому что их линки, а следовательно и домашние сети соединены через свич, или они в разных VLAN?

Подскажите какие порты необходимы для торрентов, Iptables выглядит так:
[more]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
UTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT

-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 143 -j ACCEPT


-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 20 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 1500:1550 -j A



-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

-A RH-F Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3128 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m udp -p udp --dport 161 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m udp -p udp --dport 162 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3389 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5190 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5938 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m udp -p udp --dport 5938 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9091 -j ACCEPT


-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 110 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 465 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 585 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT
-A RH-Firewal-1-INPUT -m state --state NEW -m tcp -p tcp --dport 995 -j ACCEPT
[/more]
Nat раздаю для NAS так:
-A POSTROUTING -s [NAS-адрес]/32 -o eth1 -j MASQUERADE

Через торрент клиенты сидов не видно, пиров видно.

OODНе хотите на мои вопросы ответить?
Цитата:

Что за правила такие, что за самодельная цепочка RH-... и почему INPUT и FORWARD идут в одну и туже цепочку???
Да и вообще, если это все правила, что у Вас есть, то на текущий момент разрешено ВСЁ.

Alukardd
RH- стандартные правила, которые были изначально в конфиге , порты просто подписывали...
Из правил еще есть:

Код:
*nat
*nat
REROUTING ACCEPT [0:0]
OSTROUTING ACCEPT [0:0]
UTPUT ACCEPT [0:0]

OOD
В чьём конфиге? Это железка какая-то?

Ещё раз — при таких правилах у вас разрешено абсолютно всё.

p.s. я конечно могу "смотреть в книгу и видеть там фигу", но всё же оно так как я сказал.

Народ помогите с моей проблемой, неужели не кто не пробрасывал порты, любой какой нибудь способ.

FloID aka
Вам уже дали ответ в первоначальной теме

Alukardd

Цитата:

В чьём конфиге? Это железка какая-то?

виртуальная машина на ESX поднята на базе CentOS , на CentOS Squid+iptables....
Кроме как настроек iptables больше ничего не знаю, что может блокировать поиск сидов
пиров видно без проблем.

OOD
Хорошо, спрошу по другому... Кто ЭТО настраивал? iptables, хоть и ни чего не блокирует, но настроен некорректно в принципе, я уже не говорю про незнамо зачем создана дополнительная цепочка(RH-) в firewall'е.

На сколько мне известно(см. wikipedia.org), за списком sid'ов клиент обращает к torrent tracker'у обычным hhtp запросом. Т.о. если у Вас в iptables не прописано какое-либо правило в PREROUTING цепочке которое заворачивает 80 порт на squid и/или напрямую не указан прокси сервер в torrent-клиенте, то все должно работать. В противном случае общение с трекером у Вас будет происходить через squid и очевидно, что его надо разрешить.

Alukardd
В в PREROUTING правилах 1 единственное(все что обращается по Https на реал айпи, перебрасывается на локальную машину)

Код:
-A PREROUTING -d [реал IP] -p tcp --dport 443 -j DNAT --to-destination [locolhost IP]

OOD
Цитата:

брался из гугла

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

Давайте по порядку.
У вас есть CentOS, который выступает в роли шлюза для некого NAS в вашей локалке. На CentOS как-то настроены Squid и iptables. На NAS должен заработать torrent клиент. Всё так?

Цитата:

Изменяю эти правила ничего не происходит

я Вам уже 2 раза писал и даже подчёркивал, что у Вас в правилах iptables разрешено всё и всем.
Мб Вы просто не все правила выкатываете? Давайте общаться тогда выводами команд:
iptables -vnL
iptables -t nat vnL
iptables -t mangle -vnL
Внутренние ip-адреса не надо замазывать, толку ни какого а ситуацию нам разгребать тяжелее, внешние, конечно, стоит. И тогда уже напиши внутренние ip NAS'а и шлюза.

Alukardd
Всё так!
Результаты команд:
iptables -vnL
[more]
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
168M 121G RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0. 0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
100M 69G RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0. 0.0.0/0

Chain OUTPUT (policy ACCEPT 193M packets, 140G bytes)
pkts bytes target prot opt in out source destination

Chain RH-Firewall-1-INPUT (2 references)
pkts bytes target prot opt in out source destination
121K 203M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
35421 2952K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 255
262M 189G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
182 8992 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
16769 1277K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123
6 296 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:20
1385 69052 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
59 3771 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpts:1500:1550
2033K 101M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
56 2912 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:5938
428 21188 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:8080
324K 18M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
2166K 107M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3128
16 724 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53
364K 27M ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53
24 1717 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:161
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:162
527 25788 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3389
189 9514 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:5190
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:5938
14 1656 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:5938
928 44544 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:9091
6933 361K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
4573 223K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:110
111 5456 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:465
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:585
182 11152 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:993
3867 186K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:995
110 37400 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:500
2 154 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1701
503 33226 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:1701
2 126 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1723
162 15882 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:4500
160 7680 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1313
1444K 144M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:1234
[/more]
iptables -t nat -vnL
[more]
Chain PREROUTING (policy ACCEPT 5851K packets, 376M bytes)
pkts bytes target prot opt in out source destination
1551 84551 DNAT tcp -- * * 0.0.0.0/0 [Реал айпи] tcp dpt:443 to:[локальный адрес]:443

Chain POSTROUTING (policy ACCEPT 4111K packets, 257M bytes)
pkts bytes target prot opt in out source destination
2520 154K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
1444K 71M MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
267 15476 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
459 23204 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
58089 3021K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
34303 1647K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
166K 8618K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
8413 631K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
0 0 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
0 0 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
0 0 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
88 5542 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
322 55717 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
934 44856 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
2924 145K MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
0 0 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
34 1632 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
1382 70816 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
91 4368 MASQUERADE all -- * eth1 [локальные адреса с NAT]0.0.0.0/0
[/more]
iptables -t mangle -vnL
[more]
Chain PREROUTING (policy ACCEPT 298K packets, 210M bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 182K packets, 129M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 117K packets, 80M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 208K packets, 146M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 324K packets, 226M bytes)
pkts bytes target prot opt in out source destination
[/more]

OOD
Зачем Вы опять замазали локальные адреса?) Ну да ладно...

Во, нашлось правило, которого я ждал. Знал что не может быть все разрешено.
Цитата:

1444K 144M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Правило, которое у Вас оказалось после, никогда не сработает.
Вообще использовать одну и туже цепочку для INPUT и для FORWARD не правильно.

Теперь по поводу протокола BitTorrent — прочтите этот абзац и примените прочтённое к конкретно вашему torrent-клиенту и трекеру.

Alukardd
т.е. если сделать так:

# torrent
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 6881 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
а торрент клиента насильно заставить работать на 6881 порту, то должно заработать, или я не так понял?
DHT включено было.

OOD
Вас должен инетересовать 6969 порт как я понял. Я сам не использую torrent клиентов и не запрещаю коннект на "левые" порты из локалки.

Alukardd
Сделал так:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 6969 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

торент клиента настроил так:

все равно не работает

OOD
Входящие Вам побоку, у Вас он всё-равно за NAT'ом и порты Вы не пробрасываете.

Ну тогда tcpdump Вам в руки. А так же можно обнулить счётчики в правилах iptables (iptables -Z FORWARDRH-Firewall-1-INPUT) и следить за тем какие из них меняются при обращении.

Alukardd
А подскажите пожалуйста в чем может быть проблема :
редактирую через vi iptable
не всегда применяются правила на определенные порты
например
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 6969 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 27015 -j ACCEPT
вот второе правило не хочет никак работать...
перезагрузка iptable не проходит, пока не удаляю вторую строчку...

такое ощущение, что правила для портов должны идти как то по очереди , причем tcp и udp отдельно как то описываться должны, а не в вперемешку...