Проброс 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 pfSenseRunning: /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/
-
Вы извне проверяете 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)