Как задействовать IPFW?

Как известно существует два способа подключения IPFW:
   1. Подключение скомпилированного модуля ядра при загрузке системы.
   2. Комплияция IPFW в ядро системы.

Начнем  с  последнего  -  компиляция  IPFW в ядро, в MAN-ах этот пункт достаточно подробно освещен:

Обычно ипользуются следующие опции в конфиге ядра:

           options IPFIREWALL

подключение IPFW

           options IPFIREWALL_VERBOSE

проходящие  пакеты записываются в лог-файл, при использовании опции log в правилах

           options IPFIREWALL_VERBOSE_LIMIT=100

ограничение  количества  записей  в  лог-файл  по  одному  правилу, в правилах IPFW значение можно изменить через опцию logamount

           options IPFIREWALL_FORWARD

форвардинг  пакетов, очень полезная опция при настройке прозрачного прокси  на  машине,  где  одновременно работает  IPFW и прокси-сервер (например SQUID или FROX)
  
            options IPDIVERT

подключение поддержки NATD (трансляция адресов)

           options DUMMYNET

поключение  функций управления трафиком (ограничение ширины канала, имитация  задержек  и  потерь  пакетов),  и  наконец  для  правила  по умолчанию,  которое  присутствует  в  конфиге  IPFW в любом случае под номером 65535, будет
  
           allow ip from any to any

если включена опция

           options IPFIREWALL_DEFAULT_TO_ACCEPT

либо,

           deny ip from any to any

если отсутствует.
  
После  сборки  и установки нового ядра получаем IPFW встроенный в ядро системы.
  
Теперь о подключение модулем, тут все проще и сложнее одновременно.
  
Подключение   IPFW   в  качестве  модуля  ядра,  осуществляется  одной командой:
  
        kldload ipfw

при этом загружается модуль ipfw.ko, который в стандартной поставке имеет  поддержку  функций  управления трафиком (DUMMYNET), к сожалению функции  форвардинга  (FORWARD) не поддерживаются и без перекомпиляции тут не обойтись.
  
Поддержку  демона  NATD  в  IPFW  можно получить, загрузив аналогичной командой модуль ipdivert.ko
  
         kldload ipdivert

IPFW,  загруженный  таким  образом,  содержит  всего  одно  правило по умолчанию:

         deny ip from any to any

Рассмотрим  теперь как происходит подключение IPFW в процессе загрузки операционой  системы.  Имеем  достаточно  типовые  переменные  в файле /etc/rc.conf

           firewall_enable="YES"
           firewall_script="/usr/local/etc/ipfw.rules"
           natd_enable="YES"
           natd_interface="fxp0"
           natd_flags="-same_ports"

Первая  строка  фактически  разрешает  исполнение  стартового  скрипта /etc/rc.d/ipfw,  который  в  свою  очередь,  выполняет  уже  известную команду

           kldload ipfw

если  IPFW  грузится  модулем  ядра,  затем запускает на выполнение скрипт  с  правилами  IPFW,  указанный  во  второй строке. Заметим что строка

           firewall_enable="YES"

требуется  как  для  загрузки  IPFW  в  виде  модуля (иначе запускать придется  вручную),  так  и для IPFW компиллированном в ядро (иначе не выполнится  скрипт  с  правилами из второй строки, хотя IPFW все равно запустится  с  одним  правилом  по  умолчанию).  В процессе выполнения скрипт  /etc/rc.d/ipfw  установит значение системной переменной равным единице (TRUE):
  
        net.inet.ip.fw.enable=1

Она  указывает  системе  использовать  ли  IPFW  вообще,  так как если переменная  равна  нулю  (FALSE),  то  IPFW  использоваться  не будет, независимо  от того подгружаем ли мы модулем IPFW или он скомпилирован в  ядро,  попутно  отметим  следующее:  все переменные, которыми можно управлять  через  sysctl  действуют  на  IPFW одинаково, независимо от способа подключения IPFW.

 

Продолжим строка:

        firewall_script="/usr/local/etc/ipfw.rules"

указывает расположение нашего скрипта с правилами для IPFW, в принципе её  может  и  не  быть,  но  тогда  запустится  на  исполнение  скрипт /etc/rc.firewall,   в   котором   есть   стандартные   наборы  правил, сгруппированные  в  секции  "OPEN","SIMPLE","CLOSED","UNKNOWN",  можно также  приспособить  его под свои нужды (хотя это и не наш метод :-)), например добавив секцию "RULES", тогда данная строка приобретёт вид:

        firewall_type="RULES"

По  поводу  строк  с  NATD  сказать  особо  нечего, все аналогично уже рассмотренному с той разницей что исполняется скрипт /etc/rc.d/natd, и если   IPFW   используется  в  виде  модуля  ядра  -загрузится  модуль ipdivert.ko, потом скрипт выполнит команду вида:

        natd -interface ${natd_interface} -same_ports

и  ещё,  если  IP  интефейсa  на  котором  крутится  NATD  получен  от DHCP-сервера, скрипт добавит опцию "-dynamic".

Замечание 1.

Как  все-таки  подключать  IPFW?  Пожалуй  решение такое: если FreeBSD используется  в  целях  обучения,  отладки  и  т.д. - проще подключать модулем, а если речь идет уже о "боевом" применении - лучше компиляция в ядро.

Как IPFW работает?

   Общая схема
  

 

 

Замечание 2.

IP-   Пакет,   попадая   в  фаервал  IPFW,  следует  согласно  порядку расположений  его  правил  до  первого  удовлетворяющего, где над этим IP-пакетом,  согласно данному правилу, совершаются какие-либо действия (пропускается, отбрасывается, возвращается обратно в фаервал и т.д.).

Замечание 3.

Входящие   (IN)   и   исходящие  (OUT)  пакеты  следует  рассматривать относительно   операционной   системы,   а   не  относительно  сетевых интерфейсов.

Замечание 4.

Каждый  маршрутизируемый  IP-пакет  попадает  в фаервал как на входе в операционную систему, так и на выходе из неё. Рассмотрим,  с учётом этих замечаний, следующие примеры и попытаемся в итоге  понять проходят IP-пакеты по правилам IPFW и как составлять эти самые правила.

Предположим:

1.  Система  имеет  2  сетевых интерфейса - {iif}- внутренний(fxp0) и {oif}-внешний(fxp1), псевдоинтефейc-{lo}, который мы намеренно опустим  из виду.
2.  {iip} - IP- адрес для {iif}, и соответственно {oip} - для {oif}.
3.  {MyLan} -  внутренняя сеть
4.  В  системе работает простейший демон NATD по трансляции внутренних адресов во внешний и наоборот.

Пример No.1. Как составлять правила?

Имеем  следующее  не  совсем очевидное, зато очень часто встречающееся правило:

           {fwcmd} add allow ip from {MyLan} to any

Обычно  когда  пишут такое правило - подразумевают что разрешен доступ от хостов внутренней сети к любому хосту (при этом, часто полагают что речь  идет  только о внутренней сети :-) ), но есть и еще одна сторона медали, постараюсь её показать.

С  учетом  вышеописанных замечаний данное правило распишем в следующий набор правил:

           1. {fwcmd} add allow  ip from {MyLan} to any in via {iif}
           2. {fwcmd} add allow  ip from {MyLan} to any out via {iif}
           3. {fwcmd} add allow  ip from {MyLan} to  any out via {oif}
           4. {fwcmd} add allow  ip from {MyLan}  to any in via {oif}

Правило  No.1 - мы разрешаем обращение от любого хоста внутренней сети на  любой xoст любой сети через внутренний интерфейс, аналогично и для правила No.3, но через внешний интерфейс.

Фактически  эти  два  правила разрешают  исходящие IP-пакеты от хостов внутренней сети к любым хостам любой сети.

А  теперь  о  том, что не так очевидно: правило No.2, с учётом правила No.1 фактически разрешает IP-пакеты между хостами локальной сети через интерфейс {iif}, что нормально, если предположить что в локальной сети хакеров  нет,  пользователи  послушные,  сами  на  роутер не полезут и делать там нечего плохого не будут. Однако сюрприз!

Теперь  правило  No.4  - с одной стороны оно достаточно бессмысленное. Действительно  откуда  снаружи взяться IP-пакетам от хостов внутренней сети?

Правильно - хакеры, типичный спуфинг.
Критики  могут  заметить,  что  со спуфингом умеет бороться чуть ли не каждая железяка, что демоны давно поумнели и т.д. и т.п. Тем не менее, согласитесь,  такие  правила  боевой  роутер совсем не красят, поэтому сюрприз No.2.

Можно уже делать первые выводы:

Вывод No.1.

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

Вывод No.2.

При составлении правил желательно указывать направление IP-пакетов.

Вывод No.3.

При  составлении  правил  по возможности конкретизировать сети и  IP -  адреса.

Первые  выводы  сделаны,  давайте  попробуем разобраться как IP-пакеты бегают по правилам, которые мы напишем.

Пример No.2. Связка IPFW-NATD, как работает, какие нужны правила?

Итак: исходные заданы, напишем правила IPFW, и прокомментируем их.

           #Разрешим трафик в локальной сети, конкретизировать по
           # направлению не будем и так понятно:
           1  {fwcmd} add allow  ip from {MyLan} to {MyLan} via {iif}
           #Вспомним про  NATD.
           2. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
           3. {fwcmd} add divert natd ip from any to {oip} in via {oif}
           #Роутер должен же как-то работать - изнутри мы уже все открыли,
           #будем последовательны тоже сделаем и снаружи.
           4. {fwcmd} add allow  ip from {oip} to any out via {oif}
           5. {fwcmd} add allow  ip from  any  to {oip} in via {oif}
           #Роутер у нас или нет?  Давайте разрешим локальным хостам
           # свободно лазить во внешнюю сеть.
           #Для исходящих пакетов от хостов внутренней сети.
           6. {fwcmd} add allow ip from {MyLan} to any in via {iif}
           7.{fwcmd} add allow ip from {MyLan} to any out via {oif}
           #Для входящих IP-пакетов к хостам внутренней сети.
           8. {fwcmd} add allow ip from any to {MyLan} in via {oif}
           9. {fwcmd} add allow ip from any to {MyLan} out via {iif}
           #Для порядка завершим
           10. {fwcmd} add deny ip from any to any


Получили  такой  вот  конфиг  IPFW, хотя могли обойтись всего-то одной строчкой

           {fwcmd} add allow ip from any to any

Примечание  -  Фактически  правило  No.1  не нужно, т.к. его расширили правилами No.6,No.9, однако оставим его, поскольку в реальных условиях надо  редактировать  как раз с No.6 по No.8, да и само по себе правило No.1 не самое удачное решение в плане широковещательных запросов.

Пусть   хост   внутренней  сети  (192.168.0.75)  запрашивает  почту  с gmail.com   (64.233.183.109:995),   для  нашего  роутера  внешний  IP - 195.34.32.55.

Забудем про DNS, сразу к делу - какими видит IPFW проходящие пакеты:
Правила No.-No. 1-5 не подходят, а вот No.6 как раз в точку:

           TCP 192.168.0.75:1499 64.233.183.109:995 in via fxp0


так  пошел  запрос  на  внутренний  интерфейс  (fxp0) роутера, с хоста внутренней  сети.  Операционная  система  приняла  его  и  по  таблице маршрутизации  отправила на внешний интерфейс (fxp1), здесь этот пакет стал исходящим и снова уперся в фаервал:

           TCP 192.168.0.75:1499 64.233.183.109:995 out via fxp1

тут  вступает  в  действие  NATD  (правило  No.2) он переписывает IP в заголовке  пакета, составляет таблицу где запоминает что он сотворил с пакетом  и  благополучно  отпускает  путешествовать  по  правилам IPFW дальше, что собственно будет выглядеть так:

           TCP 195.34.32.55:1499 64.233.183.109:995 out via fxp1

кстати NATD сохранил еще и первоначальный порт 1499, что бывает далеко не  всегда.  Этот  пакет  дойдет до правила No.4, благополучно покинет фаервал и отправится путешествовать в сеть.

Теперь рассмотрим как идет ответ сервера:
Ответный пакет входит в файервал снаружи через внешний интерфейс fxp1:

           TCP 64.233.183.109:995 195.34.32.55:1499 in via fxp1

как  видно  с  какого порта запросили на тот ответ и получили. Правила No.1,No.2  он  благополучно  миновал  а  в  правиле  No.3 его радостно встречает  NATD,  который  проверяет  свою  таблицу,  находит запись и переписывает заголовок уже на:

           TCP 64.233.183.109:995 192.168.0.75:1499 in via fxp1

по  правилу  No.7  пакет  выходит  из  IPFW  и попадает в операционную систему,  которая  маршрутизирует  пакет  на интерфейс внутренней сети (fxp0),  здесь  пакет  опять упрется в фаервал но уже, как исходящий с интерфейса внутренней сети fxp0.

           TCP 64.233.183.109:995 192.168.0.75:1499 out via fxp0

правило  No.9  благополучно  выпустит пакет из фаервала. Счастливый хост получил ответ на свой запрос.

Дайте  рассмотрим  ещё  один случай связки IPFW-NATD - перенаправление входящего запроса на сервер внутренней сети. Предположим мы хотим открыть для доступа снаружи Web-сервер внутренней сети с IP-адресом 192.168.0.3, для чего изменим в rc.conf строку на
  
        natd_flags="-same_ports -redirect_port tcp 192.168.0.3:80 80"

В логах IPFW можно будет увидеть примерно следующее:

           1. TCP 195.34.32.56:1076 195.34.32.55:80 in via fxp1
           2. TCP 195.34.32.56:1076 192.168.0.3:80 in via fxp1
           3. TCP 195.34.32.55:1076 192.168.0.3:80 out via fxp0
           4. TCP 192.168.0.3:80 195.34.32.56:1076 in via fxp0
           5. TCP 192.168.0.3:80 195.34.32.56:1076 out via fxp1
           6. TСP 195.34.32.55:80 195.34.32.56:1076 out via fxp1

Ситуация аналогична уже рассмотренной:
первая строка и вторая строка - один и тот же пакет - входящий запрос, который   попадает   в   NATD   через  внешний  интрефейс  fxp1.  NATD переписывает  заголовок пакета и далее по правилам IPFW пакет попадает в операционную систему.

третья  строка - пакет прошедший по таблице маршрутизации операционной системы, исходящий через внутренний интерфейс fxp0. четвертая  строка  -  ответ  сервера  входящий на внутренний интерфейс fxp0.

пятая  и  шестая  строки - один и тот же пакет, прошедший через NATD и ставший исходящим через внешний интерфейс fxp1.

Примечание:   Относительно   DIVERT   в  MAN-е  по  IPFW  присутствует присутствует   некая   двусмысленность,   согласно  MAN-у  для  пакета попавшего  под  правило  с DIVERT дальнейший поиск прекращается, а что происходит с самим пакетом - неясно.

Экпериментально  установлено,  что  в случае трансляции адресов, пакет прошедший  через  DIVERT-сокет, продолжает путь по правилам IPFW сразу после  правила  с  DIVERT,  имея  переписаный  (транслированный)  IP в заголовке.

Чтобы закончить со связкой IPFW-NATD, составим примерный список правил для конфига IPFW, обеспечивающий работоспособность данной связки :

        #Разрешаем все по интерфейсу обратной петли
        {fwcmd} add allow ip from any to any via lo
        #Разрешаем все внутри локальной сети,
        #кроме того эти правила необходимы для связки IPFW-NATD
        #Для защиты роутера от пользователей локальной сети перед этими правилами
        #нужно вcтавить что-то запрещающее
        #Если есть необходимость роутеру в широковещательных запросах
        #нужно вставить что-то разрешающее
        {fwcmd} add allow ip from {MyLan} to any in via {iif}
        {fwcmd} add allow ip from any to {MyLan} out via {iif}
        #Разрешаем входящие соединения к роутеру,
        #это правило напрямую к связке IPFW-NATD отношения не имеет,
        #оно необходимо для обеспечения работоспособности демонов роутера.
        #Естественно правило необходимо расширить с учетом потребностей демонов.
        #Внимание!!! правила расположены выше DIVERT,
        # т.е в этом примере для хостов внутренней сети
        #DNS сервер должен быть внутри сети
        {fwcmd} add allow ip from any to {oip} 53 in via {oif}
        {fwcmd} add allow ip from any 53 to {oip} in via {oif}
        #NATD для исходящих соединений
        {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
        #Внимание!!! Правило - разрешает исходящие соединения как для самого роутера,
        #так и для хостов внутренней сети, IP которых транслировал NATD
        {fwcmd} add allow ip from {oip} to any out via {oif}
        #NATD для входящих соединений
        {fwcmd} add divert natd ip from not {MyLan} to {oip} in via {oif}
        #Внимание!!! Правило - разрешает входящие соединения только к хостам внутренней сети,
        #IP которых транслировал NATD
        {fwcmd} add allow ip from not {MyLan} to {MyLan} in via {oif}
        {fwcmd} add deny ip from any to any

Ну и последнее замечание по поводу IPFW-NATD:

Что  делать  если  требуется  что-то  прикрыть  в интернете для хостов внутренней сети? Ответ достаточно очевиден:

1. Впереди правил для локальной сети (строки 2-3) пишем свои запреты. Ну  и наоборот если требуется все запретить, разрешив только что-то: к примеру HTTP?

2. Приводим строки 2-3 к следующему виду:

           {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
           {fwcmd} add allow tcp from {MyLan} to any http in via {iif}
           {fwcmd} add allow tcp from any http to {MyLan} out via {iif}

Полагаю тема связки IPFW-NATD закрыта.
Продолжим  исследования,  разберем  еще  один частоиспользуемый случай IPFW-SQUID.

Сначала  без  прозрачного  прокси. Вернемся к первому варианту конфига IPFW и рассмотрим что происходит. Вот и подходящий кусочек лога:

           TCP 192.168.0.112:1212 192.168.0.9:3128 in via fxp0

-входящий  пакет  от  внутреннего хоста к роутеру с работающим Squid - правило No.1, Squid его обработает и сам отправит в сеть.

           TCP 195.34.32.55:52439 64.12.24.102:443 out via fxp1

-исходящий пакет от SQUID к удаленному хосту - правило No.4

           TCP 64.12.24.102:443 195.34.32.55:52439 in via fxp1

-  входящий  ответ  на  интерфейс  внешней сети - правило No. 5, Squid опять же его обработал, и ответил хосту локальной сети


           TCP 192.168.0.9:3128 192.168.0.112:1212 out via fxp0

- правило No.1, пакет вышел из фаервала и побежал к адресату.
Пример несколько утрированный, однако интересен следующим:
Первое  - NATD не используется, а вернее так: в NATD входящий пакет от хоста  64.12.24.102:443  все  равно  попадет,  правило  No.3  никто не отменял.  Однако  NATD  об этом пакете ничего не знает, поэтому делать ничего  не  будет, он отправит пакет дальше путешествовать по правилам IPFW, пока последний не доберется до правила No.4.


Второе  -  сам  адресат:  64.12.24.102:443 - протокол https, а хост из сети 64.12.0.0/16 AOL-MTC, т.е. ICQ.

Продолжим,  теперь  на  очереди  прозрачный  прокси,  для него изменим правила IPFW следующим образом: добавив строку для форвардинга в итоге получим:

          1. {fwcmd} add allow  ip from {MyLan} to {MyLan} via {iif}
          2. {fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80 in via {iif}
          3. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
          4. {fwcmd} add divert natd ip from to any to {oip} in via {oif}
          5. {fwcmd} add allow  ip from {oip} to any out via {oif}
          6. {fwcmd} add allow  ip from  any  to {oip} in via {oif}
          7. {fwcmd} add allow ip from {MyLan} to any in via {iif}
          8. {fwcmd} add allow ip from {MyLan} to any out via {oif}
          9. {fwcmd} add allow ip from any to {MyLan} in via {oif}
          10. {fwcmd} add allow ip from any to {MyLan} out via {iif}
          11. {fwcmd} add deny ip from any to any

Предположим  хост  внутренней  сети  с  IP  192.168.0.100 запрашивает www.yandex.ru, на входе в фаервал имеем:

           TCP 192.168.0.100:1083 77.73.24.4:80 in via fxp0

пакет  доходит  до  правила  No.2, по которому переправляется на вход локального  прокси-сервера, далее уже знакомая картина самостоятельной обработки прокси-сервером запроса:
  
               TCP 195.34.32.55:57415 77.73.24.4:80 out via fxp1
           TCP 77.73.24.4:80 195.34.32.55:57415 in via fxp1


наконец ответ хосту, а здесь уже интересно, поскольку прокси-сервер ответил следующим образом:

           TCP 77.73.24.4:80 192.168.0.100:1083 out via fxp0

Как  видим  для  хоста внутренней сети все махинации с прокси-сервером остались не заметны.

Опять  оговоримся:  в  примере  рассмотрен  только принцип прохождения пакета, реальный лог совсем не такой однозначный. Чтобы  закончить  тему  связки IPFW-SQUD напишем примерные правила для

   IPFW:

        {fwcmd} add allow ip from any to any via lo
        #Собственно следующие строки не только для локальной сети,
        #они ещё задают варианты использование прокси для обычного достаточно
        {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
        #для прозрачного
        #Здесь мы попали в засаду с портами, впрочем это только начало
        #{fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80,443 in via {iif}
        #{fwcmd} add allow ip from {MyLan} to any 80,443 in via {iif}
        #{fwcmd} add allow ip from any 80,443 to {MyLan} out via {iif}
        #{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
        #Так подробно расписано специально чтобы была видна разница в правилах.

        #Разрешаем входящие соединения к роутеру,
        #вообще эти правила напрямую к связке IPFW-SQUID отношения не имеют,
        #правда с DNS не все так однозначно.
        {fwcmd} add allow ip from any to {oip} 53 in via {oif}
        {fwcmd} add allow ip from any 53 to {oip} in via {oif}

        #Правила для SQUID, тут чтобы опять не попасть в засаду с портами,
        #извернемся следующим образом
        {fwcmd} add deny  tcp from any to {oip} in via {oif} tcpflags syn,!ack
        {fwcmd} add allow tcp from any to {oip} in via {oif}
        #Завершим традиционно
        {fwcmd} add allow ip from {oip} to any out via {oif}
        {fwcmd} add deny ip from any to any

Расставим  точки над i - обьединим два рассморенных случая вместе, тем самым  создадим  эдакий  скелет  конфига  IPFW  для  подгонки под свои требования.

  #!/bin/sh -
  fwcmd=/sbin/ipfw

  # Внешний интерфейс
  oif=xxx
  oip=xxx.xxx.xxx.xxx

  # Внутренний интерфейс
  iif=xxx
  iip=xxx.xxx.xxx.xxx
  MyLan=xxx.xxx.xxx.0/24

  # Хосты сети, которым разрешим свободно ходить в инет  через роутер
  pdc=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx

  ${fwcmd} flush -f

  #Стандартное средство защиты от спуффинга :-)
  ${fwcmd} add deny ip from any to any not verrevpath in

  # Убьем фрагменты
  ${fwcmd} add deny ip from any to any frag

  ${fwcmd} add allow ip from any to any via lo
  ${fwcmd} add denny ip from any to 127.0.0.0/8
  ${fwcmd} add denny ip from 127.0.0.0/8 to any

  ${fwcmd} add allow ip from ${MyLan} to ${MyLan} via {iif}
  ${fwcmd} add allow ip from ${pdc} to any in via ${iif}
  ${fwcmd} add allow ip from any to ${pdc} out via ${iif}

  ${fwcmd} add divert natd ip from ${MyLan} to any out via ${oif}
  ${fwcmd} add allow ip from ${oip} to any out via ${oif}

  ${fwcmd} add divert natd ip from any to ${oip} in via {oif}
  ${fwcmd} add allow ip from any to ${MyLan} in via {oif}

  #Правила для демонов перенесли ниже потому что они
  # перекрывают входящие пакеты для NATD
  #Следующие два правила равносильны одному
  #${fwcmd} add allow tcp from any to ${oip} in via ${oif} established
  ${fwcmd} add deny  tcp from any to ${oip} in via ${oif} tcpflags syn,!ack
  ${fwcmd} add allow tcp from any to ${oip} in via ${oif}

  ${fwcmd} add allow udp from any to ${oip} 53 in via ${oif}
  ${fwcmd} add allow udp from any 53 to ${oip} in via ${oif}

  ${fwcmd} add allow icmp from any to ${oip} in via ${oif} icmptype 0,4,8,11,12

  ${fwcmd} add deny log ip from any to any

Как правило IPFW, NATD, SQUID и еще куча различных демонов крутится на одной  машине-роутере,  как  уже  было  видно  для  каждого  демона по отдельности  правила  IPFW  имеют много общего, но и каждый имеет свои нюансы,  поэтому  при  составлении  (редактировании) необходимо крайне внимательно  проверять  то  что  уже  есть,  добавляя   только  то что требуется,  иначе вместо логичной и непробиваемой огненной стены можно получить абсолютно непонятное решето.

Очень  хочется думать, что статья поможет вам в создании безопасных, а главное  осознанных правил IPFW, спасибо всем кто сумел сие прочитать, за сим откланиваюсь.

   -cat-

P.S.  Автор сознательно не использовал конструкции setup-established и check-state keep-state.

setup-established  запутали бы процесс понимания правил, keep-state же напустил бы туману еще больше.

P.P.S.   В   процессе   сочинения  сего  использовались  логи  реально работающего  роутера,   а  также  различные  виртуальные  машины, логи собраны при помощи строки {fwcmd} add count log all from any to any. Совпадения IP - реальных случайны, случайных - не реальны. ;-).