forum.opennet.ru - "PF rdr правило и bridge c AV" (11)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"PF rdr правило и bridge c AV"

Форум Открытые системы на сервере (Firewall, Фильтрация пакетов / FreeBSD)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"PF rdr правило и bridge c AV"	+/–
Сообщение от LHN on 09-Фев-12, 16:49
СОбственно не могу разобраться почему не работает правило редиректа в pf. Исходные данные: Inet -> 95.173.x.x GW(Nat) 10.1.1.1-> $Ext_if (bridge with pf) $int_if ->10.1.1.2 client На клиенте прописан default gateway 10.1.1.1 Собственно само соединение через мост работает нормально, pf фильтрует трафик, все Ок. Для организации антивирусной проверки на bridge пытаюсь прикрутить Squid+AV (DrWeb)+rdr правила вида rdr on $int_if inet proto tcp from any to any port 80 -> 127.0.0.1 port 3128 pass in quick on $int_if route-to lo0 inet proto tcp from any to 127.0.0.1 port 3128 keep state Squid соответственно слушает 127.0.0.1:3128 intercept. (К слову если сделать на бридже адрес и явно прописать его на клиенте все опять же работает, AV фильтрует) Правило даже вроде как работает, т.к. pfctl -ss дает кучу записей типа all tcp 127.0.0.1:3128 <- 82.204.218.126:80 <- 10.1.1.2:35550 CLOSED:SYN_SENT Не пойму в чем проблема. Читал, что где то еще нат нужен, но в данной конфигурации непонятно где. К тому же tcpdump на lo0 вообще пустой. По статусу соединения проблема где-то в роутинге, но вот где?
Ответить \| Правка \| Cообщить модератору

Оглавление

PF rdr правило и bridge c AV, nix, 20:09 , 09-Фев-12, (1)

PF rdr правило и bridge c AV, LHN, 20:51 , 09-Фев-12, (2)

PF rdr правило и bridge c AV, nix, 01:00 , 10-Фев-12, (3)
PF rdr правило и bridge c AV, nix, 01:06 , 10-Фев-12, (4)

PF rdr правило и bridge c AV, LHN, 06:29 , 10-Фев-12, (5)

PF rdr правило и bridge c AV, nix, 10:43 , 10-Фев-12, (6)

PF rdr правило и bridge c AV, LHN, 11:00 , 10-Фев-12, (7)

PF rdr правило и bridge c AV, nix, 11:18 , 10-Фев-12, (8)

PF rdr правило и bridge c AV, LHN, 11:41 , 10-Фев-12, (9)

PF rdr правило и bridge c AV, Глюкк, 17:41 , 13-Фев-12, (10)

PF rdr правило и bridge c AV, LHN, 08:39 , 14-Фев-12, (11)

Сообщения по теме [Сортировка по времени | RSS]

1. "PF rdr правило и bridge c AV" +/–

Сообщение от nix (??) on 09-Фев-12, 20:09

>[оверквотинг удален]
> Исходные данные:
> Inet -> 95.173.x.x GW(Nat) 10.1.1.1-> $Ext_if (bridge with pf) $int_if ->10.1.1.2 client
> На клиенте прописан default gateway 10.1.1.1
> Собственно само соединение через мост работает нормально, pf фильтрует трафик, все Ок.
> Для организации антивирусной проверки на bridge пытаюсь прикрутить Squid+AV (DrWeb)+rdr
> правила вида
> rdr on $int_if inet proto tcp from any to any port 80
> -> 127.0.0.1 port 3128
> pass in quick on $int_if route-to lo0 inet proto tcp from any
> to 127.0.0.1 port 3128 keep state
   А зачем последнее правило? В прозрачном перенаправлении трафика на сквид хватает первого.
rdr pass on $int_if inet proto tcp from any to any port 80
-> 127.0.0.1 port 3128

> Squid соответственно слушает 127.0.0.1:3128 intercept.
> (К слову если сделать на бридже адрес и явно прописать его на
> клиенте все опять же работает, AV фильтрует)
> Правило даже вроде как работает, т.к. pfctl -ss дает кучу записей типа
> all tcp 127.0.0.1:3128 <- 82.204.218.126:80 <- 10.1.1.2:35550
>  CLOSED:SYN_SENT
> Не пойму в чем проблема. Читал, что где то еще нат нужен,
> но в данной конфигурации непонятно где. К тому же tcpdump на
> lo0 вообще пустой. По статусу соединения проблема где-то в роутинге, но
> вот где?
А tcpdump что говорит на интерфейсах
  tcpdump -nqtttti _IF_NAME_

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "PF rdr правило и bridge c AV" +/–

Сообщение от LHN on 09-Фев-12, 20:51

>    А зачем последнее правило? В прозрачном перенаправлении трафика на
> сквид хватает первого.
> rdr pass on $int_if inet proto tcp from any to any port
> 80
> -> 127.0.0.1 port 3128
Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его явно не разрешить то он будет дропнут на последнем правиле deny.
>  А tcpdump что говорит на интерфейсах
>   tcpdump -nqtttti _IF_NAME_
А он весь http трафик прекрасно видит, и на int_if и на bridge0. Более того в логах pf отрабатывает именно второе правило pass in log quick...
Вот только на lo0 ничего нет, вообще...
Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if. Т.е. по логике уходя с клиента они попадают на int_if, но потом должно сработать правило редиректа, и оно как бы даже срабатывает, но этот же пакет появляется и логируется на bridge0 по второму разу.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "PF rdr правило и bridge c AV" +/–

Сообщение от nix (??) on 10-Фев-12, 01:00

>>    А зачем последнее правило? В прозрачном перенаправлении трафика на
>> сквид хватает первого.
>> rdr pass on $int_if inet proto tcp from any to any port
>> 80
>> -> 127.0.0.1 port 3128
> Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его
> явно не разрешить то он будет дропнут на последнем правиле deny.
Так вы посмотрите внимательнее. Там опция pass зачем по-вашему?
>[оверквотинг удален]
>>   tcpdump -nqtttti _IF_NAME_
> А он весь http трафик прекрасно видит, и на int_if и на
> bridge0. Более того в логах pf отрабатывает именно второе правило pass
> in log quick...
> Вот только на lo0 ничего нет, вообще...
> Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if.
> Т.е. по логике уходя с клиента они попадают на int_if, но
> потом должно сработать правило редиректа, и оно как бы даже срабатывает,
> но этот же пакет появляется и логируется на bridge0 по второму
> разу.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "PF rdr правило и bridge c AV" +/–

Сообщение от nix (??) on 10-Фев-12, 01:06

>[оверквотинг удален]
>>   tcpdump -nqtttti _IF_NAME_
> А он весь http трафик прекрасно видит, и на int_if и на
> bridge0. Более того в логах pf отрабатывает именно второе правило pass
> in log quick...
> Вот только на lo0 ничего нет, вообще...
> Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if.
> Т.е. по логике уходя с клиента они попадают на int_if, но
> потом должно сработать правило редиректа, и оно как бы даже срабатывает,
> но этот же пакет появляется и логируется на bridge0 по второму
> разу.
В догонку. Сразу забыл дописать. Если у вас мост, то нет необходимости фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с помощью sysctl
Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.pfil_bridge: 1
net.link.bridge.pfil_onlyip: 1
Посмотрите, может поможет.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "PF rdr правило и bridge c AV" +/–

Сообщение от LHN on 10-Фев-12, 06:29

>[оверквотинг удален]
> фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже
> (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с
> помощью sysctl
> Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
> net.link.bridge.log_stp: 0
> net.link.bridge.pfil_local_phys: 0
> net.link.bridge.pfil_member: 0
> net.link.bridge.pfil_bridge: 1
> net.link.bridge.pfil_onlyip: 1
> Посмотрите, может поможет.
Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в принципе пробовал и чисто на бридж правило редиректа повесить, точно так же эффекта нет.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "PF rdr правило и bridge c AV" +/–

Сообщение от nix (??) on 10-Фев-12, 10:43

>[оверквотинг удален]
>> Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса.
>> net.link.bridge.log_stp: 0
>> net.link.bridge.pfil_local_phys: 0
>> net.link.bridge.pfil_member: 0
>> net.link.bridge.pfil_bridge: 1
>> net.link.bridge.pfil_onlyip: 1
>> Посмотрите, может поможет.
> Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в
> принципе пробовал и чисто на бридж правило редиректа повесить, точно так
> же эффекта нет.
Значит, что-то не так делаете.
Попробуйте что-то вроде этого:
Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста.
set skip on {lo $int_if $ext_if}
set state-policy if-bound
rdr on bridge0 inet proto tcp from $client to !(self) port {80 443} -> 127.0.0.1 port 3128
block in all
block out all
pass in quick on bridge0 inet proto tcp from $client to bridge0
pass out quick on bridge0 from bridge0 to any
Форвардинг включать не надо.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "PF rdr правило и bridge c AV" +/–

Сообщение от LHN on 10-Фев-12, 11:00

> Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста.
Он не может слушать на интерфейсе моста, у моста нет ip.
К тому же в правилах ниже Вы предлагаете редирект на 127.0.0.1
> set skip on {lo $int_if $ext_if}
> set state-policy if-bound
> rdr on bridge0 inet proto tcp from $client to !(self) port {80
> 443} -> 127.0.0.1 port 3128
> block in all
> block out all
> pass in quick on bridge0 inet proto tcp from $client to bridge0
> pass out quick on bridge0 from bridge0 to any
И данные правила так же не применимы no IP address found for bridge0

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "PF rdr правило и bridge c AV" +/–

Сообщение от nix (??) on 10-Фев-12, 11:18

>[оверквотинг удален]
>> set skip on {lo $int_if $ext_if}
>> set state-policy if-bound
>> rdr on bridge0 inet proto tcp from $client to !(self) port {80
>> 443} -> 127.0.0.1 port 3128
>> block in all
>> block out all
>> pass in quick on bridge0 inet proto tcp from $client to bridge0
>> pass out quick on bridge0 from bridge0 to any
> И данные правила так же не применимы no IP address found for
> bridge0
))). Наверное надо немного доки почитать. Макрос вы не определили.
Удачи.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "PF rdr правило и bridge c AV" +/–

Сообщение от LHN on 10-Фев-12, 11:41

> ))). Наверное надо немного доки почитать. Макрос вы не определили.
> Удачи.
Ээээ... в каком месте макрос и при чем здесь они. вот целиком правила сейчас:
loopback = "{ lo0 }"
WAN = "{ igb3 }"
LAN = "{ igb0 }"
OPT1 = "{ igb2 }"
BRIDGE = "{ bridge0 }"
set skip on $loopback
set skip on $OPT1
set skip on $WAN
set state-policy if-bound
rdr on bridge0 inet proto tcp from 10.111.111.2 to !(self) port {80, 443} -> 127.0.0.1 port 3128
pass in log quick on bridge0  from any to bridge0
pass out log quick on bridge0 from bridge0 to any
Если нет Ip на bridge правила не загружаются. Ставлю 10.x.x.x на бридж правила загружаются.
Однако проблему это не решает.
pfctl -ss
all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710       CLOSED:SYN_SENT
all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711       CLOSED:SYN_SENT
tcpdump bridge0
2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0
2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0
2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "PF rdr правило и bridge c AV" +/–

Сообщение от Глюкк on 13-Фев-12, 17:41

>[оверквотинг удален]
> Однако проблему это не решает.
> pfctl -ss
> all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710
>  CLOSED:SYN_SENT
> all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711
>  CLOSED:SYN_SENT
> tcpdump bridge0
> 2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0
> 2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0
> 2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0
а ipfw часом не запущен?
подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT
очень даже может мешать (
на всякий пожарный дайте ему ipfw flush
и проверьте

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "PF rdr правило и bridge c AV" +/–

Сообщение от LHN on 14-Фев-12, 08:39

>>[оверквотинг удален]
> а ipfw часом не запущен?
> подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT
> очень даже может мешать (
> на всякий пожарный дайте ему ipfw flush
> и проверьте
возможно, я лично подозреваю, что проблема где-то в роутинге, т.к. есть отдельный линк в интернет для управления. и там статик роут прописан.
Попробую от него избавиться и на ipfw посмотрю.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "PF rdr правило и bridge c AV"	+/–
Сообщение от nix (??) on 09-Фев-12, 20:09
>[оверквотинг удален] > Исходные данные: > Inet -> 95.173.x.x GW(Nat) 10.1.1.1-> $Ext_if (bridge with pf) $int_if ->10.1.1.2 client > На клиенте прописан default gateway 10.1.1.1 > Собственно само соединение через мост работает нормально, pf фильтрует трафик, все Ок. > Для организации антивирусной проверки на bridge пытаюсь прикрутить Squid+AV (DrWeb)+rdr > правила вида > rdr on $int_if inet proto tcp from any to any port 80 > -> 127.0.0.1 port 3128 > pass in quick on $int_if route-to lo0 inet proto tcp from any > to 127.0.0.1 port 3128 keep state А зачем последнее правило? В прозрачном перенаправлении трафика на сквид хватает первого. rdr pass on $int_if inet proto tcp from any to any port 80 -> 127.0.0.1 port 3128 > Squid соответственно слушает 127.0.0.1:3128 intercept. > (К слову если сделать на бридже адрес и явно прописать его на > клиенте все опять же работает, AV фильтрует) > Правило даже вроде как работает, т.к. pfctl -ss дает кучу записей типа > all tcp 127.0.0.1:3128 <- 82.204.218.126:80 <- 10.1.1.2:35550 > CLOSED:SYN_SENT > Не пойму в чем проблема. Читал, что где то еще нат нужен, > но в данной конфигурации непонятно где. К тому же tcpdump на > lo0 вообще пустой. По статусу соединения проблема где-то в роутинге, но > вот где? А tcpdump что говорит на интерфейсах tcpdump -nqtttti _IF_NAME_
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "PF rdr правило и bridge c AV"	+/–
	Сообщение от LHN on 09-Фев-12, 20:51
	> А зачем последнее правило? В прозрачном перенаправлении трафика на > сквид хватает первого. > rdr pass on $int_if inet proto tcp from any to any port > 80 > -> 127.0.0.1 port 3128 Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его явно не разрешить то он будет дропнут на последнем правиле deny. > А tcpdump что говорит на интерфейсах > tcpdump -nqtttti _IF_NAME_ А он весь http трафик прекрасно видит, и на int_if и на bridge0. Более того в логах pf отрабатывает именно второе правило pass in log quick... Вот только на lo0 ничего нет, вообще... Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if. Т.е. по логике уходя с клиента они попадают на int_if, но потом должно сработать правило редиректа, и оно как бы даже срабатывает, но этот же пакет появляется и логируется на bridge0 по второму разу.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "PF rdr правило и bridge c AV"	+/–
	Сообщение от nix (??) on 10-Фев-12, 01:00
	>> А зачем последнее правило? В прозрачном перенаправлении трафика на >> сквид хватает первого. >> rdr pass on $int_if inet proto tcp from any to any port >> 80 >> -> 127.0.0.1 port 3128 > Т.к. в Pf при rdr трафик проходит через фильтры, поэтому если его > явно не разрешить то он будет дропнут на последнем правиле deny. Так вы посмотрите внимательнее. Там опция pass зачем по-вашему? >[оверквотинг удален] >> tcpdump -nqtttti _IF_NAME_ > А он весь http трафик прекрасно видит, и на int_if и на > bridge0. Более того в логах pf отрабатывает именно второе правило pass > in log quick... > Вот только на lo0 ничего нет, вообще... > Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if. > Т.е. по логике уходя с клиента они попадают на int_if, но > потом должно сработать правило редиректа, и оно как бы даже срабатывает, > но этот же пакет появляется и логируется на bridge0 по второму > разу.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "PF rdr правило и bridge c AV"	+/–
	Сообщение от nix (??) on 10-Фев-12, 01:06
	>[оверквотинг удален] >> tcpdump -nqtttti _IF_NAME_ > А он весь http трафик прекрасно видит, и на int_if и на > bridge0. Более того в логах pf отрабатывает именно второе правило pass > in log quick... > Вот только на lo0 ничего нет, вообще... > Кстати тоже странность вроде бы, одинаковые пакеты и на int_if и bridge_if. > Т.е. по логике уходя с клиента они попадают на int_if, но > потом должно сработать правило редиректа, и оно как бы даже срабатывает, > но этот же пакет появляется и логируется на bridge0 по второму > разу. В догонку. Сразу забыл дописать. Если у вас мост, то нет необходимости фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с помощью sysctl Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса. net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 0 net.link.bridge.pfil_bridge: 1 net.link.bridge.pfil_onlyip: 1 Посмотрите, может поможет.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "PF rdr правило и bridge c AV"	+/–
	Сообщение от LHN on 10-Фев-12, 06:29
	>[оверквотинг удален] > фильтровать на всех интерфейсах. Во фре можно фильтровать на самом бридже > (в опенке по-моему на бридже фильтровать нельзя). Регулируется такое поведение с > помощью sysctl > Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса. > net.link.bridge.log_stp: 0 > net.link.bridge.pfil_local_phys: 0 > net.link.bridge.pfil_member: 0 > net.link.bridge.pfil_bridge: 1 > net.link.bridge.pfil_onlyip: 1 > Посмотрите, может поможет. Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в принципе пробовал и чисто на бридж правило редиректа повесить, точно так же эффекта нет.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "PF rdr правило и bridge c AV"	+/–
	Сообщение от nix (??) on 10-Фев-12, 10:43
	>[оверквотинг удален] >> Вот с одного сервака. Там в мост объединены несколько внутр. сетевых интерфейса. >> net.link.bridge.log_stp: 0 >> net.link.bridge.pfil_local_phys: 0 >> net.link.bridge.pfil_member: 0 >> net.link.bridge.pfil_bridge: 1 >> net.link.bridge.pfil_onlyip: 1 >> Посмотрите, может поможет. > Спасибо, такие параметры есть, фильтрую и на бридже и на интерфейсах, в > принципе пробовал и чисто на бридж правило редиректа повесить, точно так > же эффекта нет. Значит, что-то не так делаете. Попробуйте что-то вроде этого: Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста. set skip on {lo $int_if $ext_if} set state-policy if-bound rdr on bridge0 inet proto tcp from $client to !(self) port {80 443} -> 127.0.0.1 port 3128 block in all block out all pass in quick on bridge0 inet proto tcp from $client to bridge0 pass out quick on bridge0 from bridge0 to any Форвардинг включать не надо.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "PF rdr правило и bridge c AV"	+/–
	Сообщение от LHN on 10-Фев-12, 11:00
	> Включите фильтрацию только на бридже. Squid "слушает" на интерфейсе моста. Он не может слушать на интерфейсе моста, у моста нет ip. К тому же в правилах ниже Вы предлагаете редирект на 127.0.0.1 > set skip on {lo $int_if $ext_if} > set state-policy if-bound > rdr on bridge0 inet proto tcp from $client to !(self) port {80 > 443} -> 127.0.0.1 port 3128 > block in all > block out all > pass in quick on bridge0 inet proto tcp from $client to bridge0 > pass out quick on bridge0 from bridge0 to any И данные правила так же не применимы no IP address found for bridge0
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "PF rdr правило и bridge c AV"	+/–
	Сообщение от nix (??) on 10-Фев-12, 11:18
	>[оверквотинг удален] >> set skip on {lo $int_if $ext_if} >> set state-policy if-bound >> rdr on bridge0 inet proto tcp from $client to !(self) port {80 >> 443} -> 127.0.0.1 port 3128 >> block in all >> block out all >> pass in quick on bridge0 inet proto tcp from $client to bridge0 >> pass out quick on bridge0 from bridge0 to any > И данные правила так же не применимы no IP address found for > bridge0 ))). Наверное надо немного доки почитать. Макрос вы не определили. Удачи.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "PF rdr правило и bridge c AV"	+/–
	Сообщение от LHN on 10-Фев-12, 11:41
	> ))). Наверное надо немного доки почитать. Макрос вы не определили. > Удачи. Ээээ... в каком месте макрос и при чем здесь они. вот целиком правила сейчас: loopback = "{ lo0 }" WAN = "{ igb3 }" LAN = "{ igb0 }" OPT1 = "{ igb2 }" BRIDGE = "{ bridge0 }" set skip on $loopback set skip on $OPT1 set skip on $WAN set state-policy if-bound rdr on bridge0 inet proto tcp from 10.111.111.2 to !(self) port {80, 443} -> 127.0.0.1 port 3128 pass in log quick on bridge0 from any to bridge0 pass out log quick on bridge0 from bridge0 to any Если нет Ip на bridge правила не загружаются. Ставлю 10.x.x.x на бридж правила загружаются. Однако проблему это не решает. pfctl -ss all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710 CLOSED:SYN_SENT all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711 CLOSED:SYN_SENT tcpdump bridge0 2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0 2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0 2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "PF rdr правило и bridge c AV"	+/–
	Сообщение от Глюкк on 13-Фев-12, 17:41
	>[оверквотинг удален] > Однако проблему это не решает. > pfctl -ss > all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37710 > CLOSED:SYN_SENT > all tcp 127.0.0.1:3128 <- 194.67.33.56:80 <- 10.111.111.2:37711 > CLOSED:SYN_SENT > tcpdump bridge0 > 2012-02-10 11:40:19.889628 IP 10.111.111.2.44362 > 194.67.33.62.80: tcp 0 > 2012-02-10 11:40:20.657694 IP 10.111.111.2.38670 > 62.213.71.224.80: tcp 0 > 2012-02-10 11:40:20.657702 IP 10.111.111.2.38671 > 62.213.71.224.80: tcp 0 а ipfw часом не запущен? подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT очень даже может мешать ( на всякий пожарный дайте ему ipfw flush и проверьте
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "PF rdr правило и bridge c AV"	+/–
	Сообщение от LHN on 14-Фев-12, 08:39
	>>[оверквотинг удален] > а ipfw часом не запущен? > подозреваю, что так оно и есть, ибо у вас CLOSED:SYN_SENT > очень даже может мешать ( > на всякий пожарный дайте ему ipfw flush > и проверьте возможно, я лично подозреваю, что проблема где-то в роутинге, т.к. есть отдельный линк в интернет для управления. и там статик роут прописан. Попробую от него избавиться и на ipfw посмотрю.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору