Проброс 53(tcp/udp) порта на локальный DNS сервер

[Hoper]

Задача по пробросу портов понятна и описана (сделана) много раз.
работает на этом сервере (2.2.1-RELEASE (i386) ) на реальной машине.
wan - pppoe (со статикой в несколько IP через Virtual IPs)
lan - dmz

Что стоит:

• System - Advansed - FireWall/NAT - NAT Reflection mode for port forwards = enabled NAT +Proxy

• Services - DNS forwarder - Disabled

• WAN - Block private networks - включено,  Block bogon networks - включено

Правила NAT:

ATLPULL TCP         * * 1.2.3.4 3389 (MS RDP) 192.168.1.9 3389 (MS RDP) (сделано для теста)
ATLPULL TCP/UDP * * 1.2.3.4 53 (DNS)    192.168.1.9 53 (DNS)

Автоматически созданные правила:

IPv4 TCP         * * 192.168.1.9 3389 (MS RDP) * none
IPv4 TCP/UDP * * 192.168.1.9 53 (DNS) * none

Сервер DNS 192.168.1.9 шлюз у него pfSense

Результаты:
NMap c pfSense

Running: /usr/local/bin/nmap  -sU -e bge0 '192.168.1.9'

Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-25 12:23 FET
Nmap scan report for 192.168.1.9
Host is up (0.00038s latency).
Not shown: 998 open|filtered ports
PORT    STATE SERVICE
53/udp  open  domain

$sudo nmap -sU -p53 1.2.3.4

Host is up (0.0025s latency).
PORT   STATE         SERVICE
53/udp open|filtered domain

Попытка запросить у него зону (мы поддерживаем свою зону)

nslookup info.domain.ltd 1.2.3.4
;; connection timed out; no servers could be reached

К RDP подключается
DNS запросы не выдает  :( , правила, как видите, идентичны.
В чем может быть проблема? Куда копать?

[werter]

Вы извне проверяете nslookup info.domain.ltd 1.2.3.4 ?

Логи fw на pf посмотрите при nslookup info.domain.ltd 1.2.3.4

P.s. При таких условиях я бы еще Suricata прикрутил к pfsense - http://pfsensesetup.com/tag/suricata/

[Hoper]

@werter:

Вы извне проверяете nslookup info.domain.ltd 1.2.3.4 ?

Угу, с другого канала.
@werter:

Логи fw на pf посмотрите при nslookup info.domain.ltd 1.2.3.4

Что то вот с логами тут не очень хорошо. :( Те что можно смотреть в WEB-интерфейсе как то не очень информативны.
Что то там упускается. Сейчас разбираюсь на предмет включения полного логирования. И возможности смотреть это дело с консоли.
@werter:

P.s. При таких условиях я бы еще Suricata прикрутил к pfsense - http://pfsensesetup.com/tag/suricata/

Стоял Snort для этого дела, но был снесен для чистоты эксперимента.

[werter]

Что то вот с логами тут не очень хорошо.  Те что можно смотреть в WEB-интерфейсе как то не очень информативны.

На предмет блокирования\разрешения - вполне информативны. Другое дело, что далеко не все этим пользуются.
Вплоть до вопроса "Гы, а де оно включается это логирование ?"

[Hoper]

хм, немного не понял логику работы, но проблема решилась таких образом:
Добавлю к исходным данным.
интерфейсы: 2 физических 3 логических
1. LAN (eth0) - это внутренняя сеть DMZ
2. WAN (xl0) - это провайдер с PPPOE (1.2.3.4)
3. ATLPULL (xl0) - это статика провайдера (1.2.3.5)
но поскольку провайдер выдал 8 IP остальные повесил на VirtualIPs (1.2.3.6,7,8,9…) и привязал их к интерфейсу ATLPULL

В NAT указывал инт. ATLPULL как входящий и дальше выбирал IP из VirtualIPs как Destination и далее редирект -> внутренний сервер:порт
Все работало для 80,443,3389(для теста :) )!!!
Делаю копию правила для 53 порта - затуп :(
Два дня бился, звонил провайдеру - ничего не блокируют (!67,68,1137-139,445 :) )

От безысходности решил сменить привязку VirtuslIPs, привязать их к WAN. Ну и соответственно в правиле NAT сменил интерфейс ATLPULL -> WAN
OOOPS!!!  :o - ответило.

По итогу оказалось, что надо было сразу привязку правила NAT делать к WAN (VirtuslIPs можно оставить на ATLPULL - как то логичнее)