NAT com redirecionamento RDP, não funciona.
-
@ivanildogalvao said in NAT com redirecionamento RDP, não funciona.:
Sim, tanto WAN, como LAN, nada chegando para a 3389.
Na WAN, não vai bater nada na 3389, o destino do pacote vai ser o IP da WAN, e porta de destino vai ser a porta 3390, ou 3387 ou a 3381.
@ivanildogalvao said in NAT com redirecionamento RDP, não funciona.:
Mermão que irônico, isso é básico e já fiz outras vezes em outras versões de pfSense, faço até hoje com Sophos e Fortigate e de boa.
O pfsense teve um bug na versão 2.5.1 onde o portforward, em multiwan, estava causando assimetria, onde o pacote chegava por uma WAN, e o pfsense devolvia pela WAN default, bug corrigido na versão 2.5.2. Está saindo a versão 2.6.0 muito em breve, estava previsto para hoje mesmo...
@ivanildogalvao said in NAT com redirecionamento RDP, não funciona.:
Estou achando que ele se enrola com as várias regras de firewall que ele cria para a 3389, mas cada uma associada ao seu NAT, tanto que quando adicionei uma segunda regra, usando a 3382 >>>>> 3389, a anterior que era 3389 pura, parou de funcionar.
Você não está seguindo as sugestões que eu dei... Como olhar os logs pra ver se está dando match nas regras de Firewall que o pfsense criou automaticamente lá pelo NAT.
Você pode criar regras de NAT especificando para não criar uma regra de NAT, e após isso você cria manualmente as regras de Firewall permitindo o acesso nas portas 3390, ou 3387 ou a 3381. -
@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.
