NAT com redirecionamento RDP, não funciona.
-
@mcury Sim claro, na WAN não chegará nada na 3389, viagem minha, chegou quando o NAT era puro digamos assim, 3389 >>>> 3389 e até funcionou.
Sim, eu marquei para registrar logs na regra correspondente ao NAT 3390 >>>> 3389 por exemplo e nada chegou, em System Logs > Fiewall, comentei só do capturador de pacotes, foi mau.
Bem, NAT normal 3389 para a mesma porta, funciona, com portas diferentes não.
E como comentei antes, com outros serviços está ok, como 9090 >>>> 80, tem outra 8181 >>>>> 80, funciona.
Esse pfSense tem 3 links WAN, está virtualizado em um host ESXi 6.5, versão 2.5.2-RELEASE (amd64).
-
@ivanildogalvao Você está logando os pacotes dropados pela regra block implícita? Acho que é habilitado por default para logar, mas caso não esteja, faz isso clicando na chave lá nos logs de firewall
Pesquisa nos logs pra confirmar se a porta 3390 está sendo bloqueada na WAN
-
@mcury Cara, vou dar uma imprensada aqui no cara do suporte neste cliente, validei com ele gateway e firewall do Windows, me disse que estava ok, mas vou insistir em querer ver, pois vi nos logs aqui pacotes chegando na WAN, sendo direcionados para o IP LAN da máquina na 3389 e o IP de origem é justamente o do meu modem aqui.
Não é possível que o cara tenha me feito bater cabeça e perguntei várias vezes, vou pedir para ver a máquina, via anydesk.
-
@ivanildogalvao go to firewall wan rules
post your wan rule please.
-
@itg Então o IP público não está chegando direto no pfsense?
Foi aquele esquema de DMZ no modem? Tenta por em bridge... Esse esquema de DMZ as vezes faz NAT para dentro, o que mascara o IP de origem... -
@mcury Não, digo checar direto na máquina Windows mesmo, se de repente não tem duplo gateway e se realmente o firewall local está habilitado.
-
@itg Ok, mas se o IP que está chegando na WAN do pfsense é o IP do modem, é porque o modem não está em bridge... dá uma conferida nisso também.
Alguns modem/router fazem NAT quando quando põe o IP na DMZ, e outros não, mas pode ser o caso por aí. -
@mcury O modem está em bridge, o IP que chega no pfSense é o publico, por onde entram outros serviços inclusive, como DVR, Central Telefônica IP, Servidor Web.
E mesmo assim, o pfSense tem 3 links WAN com IP público, já testei com todos.
E como eu disse, se eu colocar uma só regra WAN 3389 chegando na máquina LAN 3389, funciona. A partir do momento que adiciono outra, WAN 3387 chegando em outra máquina na 3389, além desta não funcionar, a anterior para de funcionar.
Eu acho que é algum bug no pfSense.
Olha essa captura aqui na LAN, no momento que tento conectar aqui do meu escritório.
11:22:40.361272 IP 177.87.x.x.17322 > 192.168.0.173.3389: tcp 0
11:22:40.361638 IP 192.168.0.173.3389 > 177.87.x.x.17322: tcp 0
11:22:40.880856 IP 177.87.x.x.17322 > 192.168.0.173.3389: tcp 0
11:22:40.881275 IP 192.168.0.173.3389 > 177.87.x.x.17322: tcp 0 -
@mcury Corrigindo uma informação. A regra de NAT pura, ou seja, porta 3389 para a 3389, funciona com ou sem as outras, mas só ela.
As demais, tipo: 3390 para 3389, 3387 para a 3389, 3386 para a 3389, nada feito.
-
@itg A captura está certa, conexão bidirecional, cliente atingindo o servidor e o mesmo respondendo, já fez o download dessa captura e abriu no wireshark para ver o que pode estar acontecendo?
Em relação a bug do pfsense, acho muito improvável pois já teriam outros usuários reclamando por aqui...
Repete essa captura na porta 3390, faz o teste e vê se o pacote está indo para o IP 192.168.0.20 na porta 3389, vê se tem comunicação ida e volta também
-
@mcury Sim tem razão, se fosse bug teria muita gente gritando.
Cara, sei não mais não :)
Quanto ao capture na 3390, segue:
11:44:18.000047 IP 177.87.x.x.62463 > 189.124.138.x.3390: tcp 0
11:44:18.000489 IP 189.124.138.x.3390 > 177.87.x.x.62463: tcp 0
11:44:18.512471 IP 177.87.x.x.62463 > 189.124.138.x.3390: tcp 0
11:44:18.512972 IP 189.124.138.x.3390 > 177.87.x.x.62463: tcp 0 -
@itg o pfsense está recebendo o pacote na WAN na porta 3390, e pelo que tudo indica há resposta do servidor.
Pode repetir esse teste na LAN, mas altera a porta para a 3389.
Seria bom fazer o download dessa captura e abrir no wireshark pra ver... -
@mcury Também chega.
11:55:49.107258 IP 177.87.x.x.61449 > 192.168.0.20.3389: tcp 0
11:55:49.107612 IP 192.168.0.20.3389 > 177.87.x.x.61449: tcp 0
11:55:49.616495 IP 177.87.x.x.61449 > 192.168.0.20.3389: tcp 0
11:55:49.616799 IP 192.168.0.20.3389 > 177.87.x.x.61449: tcp 0Segue imagem do Wireshark.
-
@itg Ok, não está fechando o TCP three way handshake, mas tem um RESET aí, o que me parece ser o servidor dando toco na conexão, e não um drop normal.
Pode repetir o teste na LAN, acho que é a terceira vez que peço isso rsrsrs -
@mcury Mas nesse capture estou selecionando a interface LAN :)
-
@itg E por que a captura está pegando o IP de destino como 189.124.x.x ? Esse não é um IP privado, e nem o IP que estava no NAT...
Olha aqui como fica:
-
@itg said in NAT com redirecionamento RDP, não funciona.:
Tipo, o que chegar na WAN Address, porta 3390, dirección para máquina interna 192.168.0.20, porta 3389
I am following this publication and I would like to know what is the operating system of your machine that listens to RDP
-
@silence Windows 7.
-
@mcury Rapaz é assim como estou fazendo, com a porta 3389 e são os resultados que te mandei.
E tanto faz com modo promíscuo ou não, o resultado é o mesmo.
-
@itg Na captura da LAN, o destino do pacote deveria ser 192.168.0.20, 192.168.0.173, ou 192.168.0.69.
Tem alguma coisa estranha por aí que não consegui entender ainda, esse IP 189.124.X.X é a sua WAN ?