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



  • Задача по пробросу портов понятна и описана (сделана) много раз.
    работает на этом сервере (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 запросы не выдает  :( , правила, как видите, идентичны.
    В чем может быть проблема? Куда копать?
    ![2015-03-25 12:14:26.png](/public/imported_attachments/1/2015-03-25 12:14:26.png)
    ![2015-03-25 12:14:26.png_thumb](/public/imported_attachments/1/2015-03-25 12:14:26.png_thumb)
    ![2015-03-25 12:14:53.png](/public/imported_attachments/1/2015-03-25 12:14:53.png)
    ![2015-03-25 12:14:53.png_thumb](/public/imported_attachments/1/2015-03-25 12:14:53.png_thumb)



  • Вы извне проверяете 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/



  • @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 для этого дела, но был снесен для чистоты эксперимента.



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

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



  • хм, немного не понял логику работы, но проблема решилась таких образом:
    Добавлю к исходным данным.
    интерфейсы: 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 - как то логичнее)

    ![2015-03-27 11:05:25.png](/public/imported_attachments/1/2015-03-27 11:05:25.png)
    ![2015-03-27 11:05:25.png_thumb](/public/imported_attachments/1/2015-03-27 11:05:25.png_thumb)


Log in to reply