и вот это
CFLAGS+= -DIPFIREWALL_NAT

лишнее

3 дня полет нормальный...

Внизу примеры

В make.conf указывать флаг совершенно не обязательно (и откуда только это пошло...С бета-версий, что ли?)

Раньше при использовании демона (natd только транслировал), а решение о разрешении ли запрете пакета формировались правилами после трансляции
И так было удобно поскольку можно было добавить разрешающие правила, а остальное все запретить

поэтому предпочитаю ipnat

Пытался так:
Политика по умолчанию deny all
пока net.inet.ip.fw.one_pass: 1
${fw} nat 100 config ip ${ExtIPwebserv}
${fw} add nat 100 tcp from any ${outports} to ${ExtIPwebserv} 80 in via ${WAN0}
${fw} add allow tcp from any ${outports} to 217.117.93.230 80 in via ${WAN0}
${fw} add nat 100 tcp from ${IntIPwebserv} 80 to any ${outports}
${fw} add allow tcp from any ${outports} to ${IntIPwebserv}80

Судя по ipfw всё останавливается на первом нате. Т.е. снаружи пакеты приходят, заворачиваются в нат и всё. tcpdump показывает приходящие на внешний интерфейс соединения, которые обрабатываются, а потом оно почему-то (если убрать in via ${WAN0}) посылается само на себя.

Более грамотный вариант, который я видел на http://forum.lissyara.su/viewtopic.php?f=8&t=7930&p=70395 такого рода (у меня не заработало):

${fw} nat 100 config ip ${ExtIPwebserv} redirect_port tcp ${IntIPwebserv}:80 80
ipfw add nat 100 tcp from any ${outports} to ${ExtIPwebserv} 80 via ${WAN0}
ipfw add allow tcp from any ${outports} to ${IntIPwebserv} 80 via ${LAN}
Всё замечательно, один косяк: при выходе пакеты пытаются пролезть без ната, т.е. ответы пользователям лезут с обратным внутренним IP, а не внешним.

Может кто-нибудь пояснить это синтаксис ${fw} nat 100 config ip ${ExtIPwebserv} redirect_port tcp ${IntIPwebserv}:80 80
Мозгов не хватает осилить.
И кстати, кто знает как сбрасывать правила ната? после рестарта скрипта с ipfw -f flush почему-то ipfw nat config показывает не только новые конфигурации, но старые
Может, кто приведёт рабочий скрипт для web-сервака с kernel ipfw nat?

firewall_enable="YES"
firewall_type="OPEN"

firewall_nat_enable="YES"
firewall_nat_interface="vlan0"
firewall_nat_flags="same_ports redirect_port tcp 192.168.1.30:210 210 redirect_port tcp 192.168.2.1:6112 6112"

Если так:

natd_enable="YES"
natd_flags="-redirect_port tcp 192.168.1.30:210 210 -redirect_port tcp 192.168.2.1:6112 6112 -unregistered_only -use_sockets -same_ports  -punch_fw 19000:100"
natd_interface="vlan0"

то все работает нормально.

Коротко: судя по трафику, пакеты syn пробрасываются натом нормально на внутренний комп, но syn ack уходят от нее с нулевым чексумом, поэтому tcp connection не создается. (это я смотрю на стороне внутреннего сервера w2k3sp2 куда перебрасываются порты)
В тоже самое время, при прохождении через роутер(фря 7,2 stable) нормально эти пакеты принимает и ставит туда нормальный чексум и отправляет syn ack отправителю.

w2k3sp2(куда пробрасываются порты) пытался грузить в safe mode чтобы вырубить всевозможные левые фильтры, результат такой же, т.е. что то я понаписал в настройках ipfw не то.

это читал. http://www.lissyara.su/?id=1967
не помогло
если можете помочь, могу логи и конфиги выслать. Если кто то с таким сталкивался помогите. Я точно знаю, что я где-то загигулинку не поставил, но где не знаю.

за исключением что там остановка происходит на криптографической библиотечке....

http://unix.derkeiler.com/pdf/Mailing-Lists/FreeBSD/stable/2005-11/0443.pdf если быть точнее происходит примерно это

наткнулся тут еще на это
http://periscope.opennet.ru/openforum/vsluhforumID1/83520.html
может еще что нужно поправить в make.conf? есть идеи?

попробовал поковырять make.conf в соответствии с вышеупомянутым материалом....не помогает...такое ощущение что зря cvsup делал со stabble-supfile вместо standard-supfile...

до этого 7.1 обновлял до 7.2 и качал патчи до 7.2-p2.......сейчас кажется патчи докатываются до p3