Проброс порта из LAN в WAN
-
@Konstanti
Сквид умеет в 2-ух режимах. В каком он у ТС - я хз.А если мне надо TCP\53-й порт вовне открыть на пф? Его тоже со сквидом "согласовывать" ?
И зачем в ситуации ТС-а порт-форвардинг? Снова начинаем "мудрить"?ТС-у попробовать, как и посоветовал.
Не выйдет, то:если сквид в траснпаренте
nguvu.org/pfsense/pfSense-proxy-configuration/
Transparent Proxy Settings -> Bypass proxy for these destination IPs и внести адрес удален. машиныилиhttps://forum.netgate.com/topic/132591/AppleStore -
docs.diladele.com/faq/squid/allow_non_standard_port_through_squid.html
In default installation Squid does not allow HTTP or HTTPS connections to non standard ports (defaults for HTTP is port 80 and for HTTPS port 443). If you try to connect to URLs like http://www.example.com:8080 or https://www.exampe.com:8443 your browser will show the Access Denied Squid page.
А к стандартному rdp-клиенту сквид точно "отношения" не имеет (в нем и протокол-то собственный - RDP) . А простое правило fw на ЛАН - имеет.
Это если RDP over HTTPS, тогда - да. И прийдется сквидовские Additional SSL Ports и Additional Safe Ports "крутить", если rds gw будем на нестанадртный порт вешать:
winitpro.ru/index.php/2018/10/30/rdp-web-client-html5-na-windows-rds/
1cloud.ru/help/windows/nastrojka-remote-desktop-gateway -
Прокси не прозрачный. Пробовал на другой машине, где прокси не настроен - результат тот же.
Итак, проделал всё заново: создал правило (указано в первом посте), telnet по порту 3389 не проходит, в логах опять такая фраза:
LAN tcp 192.168.0.149:1735 -> <внешн.IP>:3389 (192.168.0.7:3389) CLOSED:SYN_SENTВ сети есть Usergate, на нем NAT по порту 3389 и вообще по любому работает отлично через ту же циску. Значит циска не причем, либо у пф используются какие-то совсем другие механизмы, возможно одного правила нат недостаточно.
@werter Если не NAT, то каким образом мне обеспечить доступность внешних ресурсов, отличных от 443 и 80?
Забыл еще упомянуть, пф не является шлюзом, шлюз - циска.
-
@silh Покажите вывод tcpdump на WAN интерфейсе при пробросе 3389
У меня есть подозрение , что проблема именно в Cisco
Но для этого надо понимать , что происходит у Вас на WAN интерфейсе
192.168.0.149 - хост , инициирующий соединение ?
192.168.0.7 - это LAN PF ? -
@Konstanti уточните пожалуйста, как это сделать. Ранее не пользовался этим.
-
@silh или из консоли
tcpdump -netti имя_wan_интерфейса tcp and port 3389Или
В webgui
/diagnostics/packet capture -
@Konstanti
вот что вышло
17:05:18.569764 IP 192.168.0.149.9841 > <внешн.ip>.3389: tcp 0
17:05:19.569990 IP 192.168.0.149.9841 > <внешн.ip>.3389: tcp 0
17:05:21.570318 IP 192.168.0.149.9841 > <внешн.ip>.3389: tcp 0
17:05:25.571944 IP 192.168.0.149.9841 > <внешн.ip>.3389: tcp 0192.168.0.149 - машина, с которой инициируется соединение
192.168.0.7 - адрес лан-порта ПФ -
@silh Если это показания с WAN интерфейса, то тут можно сделать такой вывод
1 что исходящие пакеты не натируются
2 ответа нет
У меня есть подозрение , что Cisco ничего не знает про сеть 192.168.0.0/24 , поэтому ответных пакетов нет. -
Удалите ваше правило форвардинга из 1-го поста. Тем более, что оно у вас неверное.
Прaвильно (если машина с rdp внутри вашей лок. сети):
Interface - WAN
Protocol - TCP
Source Address - *
Source Ports - *
Dest. Address - WAN address
Dest. Ports - 3389 (MS RDP)
NAT IP - <ip-адрес-машины-с-RDP-внутри-вашей-сети>
NAT Ports - 3389 (MS RDP)У Вас машина с rdp где нах-ся? Вовне или в вашей сети? Если в вашей сети, то на кой ляд вы проверяете доступ к этой машине из ЛАН обращаясь к ВАН пф? Проверяйте извне.
И циску свою тормошите на предмет возможности форвардинга портов на ВАН вашего пф.Зы. Не забывайте, что по дефолту пф на ВАН блокирует все из "серых" сетей. Возможно, что в вашем случае надо откл. эту блокировку.
Зы2. Скрины правил fw на ЛАН, ВАН покажите.
Зы3. И да. Оч. глупо выставлять в мир RDP-порт ничем не прекрывшись. ВПН в этом случае решает.
-
@werter
В первом посте я конкретно описала задачу: я из локальной сети хочу подключиться к машине по RDP, находящейся в интернете, не знаю, что еще надо сказать, чтобы точнее описать ситуацию.
Вот схема
В общем поднял дома чистый ПФ. Создал аналогичное правило НАТ - заработало! Дома копеешный роутер Asus.
Видимо дело и правда в циске, но вот что не пускает обратные пакеты понять пока не могу - IP пфсенса добавлен в access-list роутераExtended IP access list 150
110 permit ip host 192.168.1.10 any (22131 matches)создано правило nat
ip nat inside source list 150 interface Dialer1 overloadНо это наверное уже не в этот форум )
Хотя если есть знакомые с циской товарищи, буду рад услышать какие-нибудь комментарии.!upd. Обновил схему сети
-
@silh said in Проброс порта из LAN в WAN:
Extended IP access list 150
110 permit ip host 192.168.1.10 any (22131 matches)Здр
Судя по тому , что Вы показали выше (вывод tcpdump на WAN интерфейсе)
то пакеты с PF уходят в стоону с ip адресом 192.168.0.149
попробуйте добавить на cisco , ради интереса
Extended IP access list 150
115 permit ip 192.168.0.0 0.0.0.255 anyи проверьте таблицу маршрутизации cisco ( знает ли она , что сеть 192.168.0.0/24 находится за pfsense ? )
-
@Konstanti
прямой доступ машины через циску тоже есть
90 permit ip host 192.168.0.149 anyМожет быть обратный пакет заворачивается сразу на локальную машину через шлюз 192.168.0.1?
Но опять же, есть Usergate в сети. У него тоже внешний IP в подсети 192.168.1.0, внутренний в 192.168.0.0 (на схеме можно поставить его просто вместо pf) - через него то NAT работает.
-
@silh
Покажите таблицу маршрутизации Cisco
и правила NAT Outbound PFsense
Судя по схеме , которую Вы нарисовали , у Вас ассиметричная маршрутизация -
@Konstanti
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C 192.168.240.0/24 is directly connected, Vlan3
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
S 172.16.13.16/30 [1/0] via 172.16.13.21
C 172.16.13.20/30 is directly connected, FastEthernet1
C 172.16.13.0/28 is directly connected, FastEthernet1
S 192.168.4.0/24 [1/0] via 172.16.13.4
xxx.xxx.0.0/32 is subnetted, 1 subnets
C xxx.xxx.xxx.xxx is directly connected, Dialer1
92.0.0.0/32 is subnetted, 1 subnets
C xxx.xx.xx.xx is directly connected, Dialer1
S 192.168.5.0/24 [1/0] via 172.16.13.5
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Loopback99
S 192.168.6.0/24 [1/0] via 172.16.13.6
S 192.168.7.0/24 [1/0] via 172.16.13.7
C 192.168.0.0/24 is directly connected, Vlan1
C 192.168.1.0/24 is directly connected, Vlan2
S 192.168.3.0/24 [1/0] via 172.16.13.3
S* 0.0.0.0/0 is directly connected, Dialer1Правил Outbound на pf нет
-
@silh
Вы сами ответили на все вопросы
1 C 192.168.0.0/24 is directly connected, Vlan1
2 Cisco пытается напрямую отправить пакет хосту - результат , ассиметричная маршрутизация
3 создайте правило Исходящего нат на интерфейсе WAN PF для хоста 149 , и будет Вам счастье -
@Konstanti
Какого вида должно быть правило? Поможет ли оно, если обратные пакеты до этого WAN PF даже не доходят? -
@silh
Причину, почему пакеты не доходят, я Вам указал выше
-
@Konstanti
Заработало!
Объясните, если не сложно, в чём суть правила Outbound? -
Добрый.
@silhСхема вашей сети просто "шикарна"(
У вас только один ПК и к циске и к пф подключен одновременно? Или такие же чудеса со всей ЛАН?
Вы уж определитесь КАК должна работать вверенная вам сеть.Зы. Вам бы подошел вариант, когда все ppp-линки поднимает пф , а циска отвечает только за ВЛАНы (т.е. работает как Л2-свитч).
-
@werter
Никаких чудес нет.
Пф был запущен на недавно и играет роль только прокси сервера со статистикой, в полутестовом режиме, так сказать.
Как пойдет дальше, покажет время. Спасибо за рекомендации.
