NAT com redirecionamento RDP, não funciona.
-
@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 ? -
-
@mcury É sim, IP da WAN.
-
@itg said in NAT com redirecionamento RDP, não funciona.:
@mcury É sim, IP da WAN.
Ok, se é o IP da WAN_CABO, o NAT não está acontecendo.
O pacote chega na WAN_CABO:
IP de origem: IP da Internet de onde você está vindo
Porta de origem: Qualquer uma
IP de destino: IP da WAN_CABO
Porta de destino: 3390
Pacote sendo direcionado a LAN:
IP de origem: IP da Internet de onde você está vindo
Porta de origem: Qualquer uma
IP de destino: IP do servidor na LAN (no seu caso 192.168.0.20).
Porta de destino: 3389No exemplo abaixo, fiz dois testes:
Criei duas regras de NAT assim como você criou:
Acessei o site: https://canyouseeme.org/
E nesse site, fiz dois testes, um para cada porta, 3390 e 3391, ambos direcionaram conforme a regra de NAT está configurada, observe acima...
No seu caso, na captura na interface LAN, o IP de destino aparece como IP da WAN_CABO...
-
@mcury Espera que deve ter tido uma enrolada de informação aqui, mandei dois captures, um de WAN e outro LAN, olha fiz agora de novo um na LAN, na 3389.
O IP publico aqui em questão é o do meu modem, aqui no meu escritório, indo em direção ao pfSense do cliente, segue:
15:42:40.809038 IP 177.87.x.x.61462 > 192.168.0.20.3389: tcp 0
15:42:40.809439 IP 192.168.0.20.3389 > 177.87.x.x.61462: tcp 0
15:42:41.318566 IP 177.87.x.x.61462 > 192.168.0.20.3389: tcp 0
15:42:41.318954 IP 192.168.0.20.3389 > 177.87.x.x.61462: tcp 0 -
É o firewall do WIndows lá, checa lá isso antes de continuarmos, se não vai ser perda de tempo... Precisa ter uma regra...
O caso de funcionar antes pelo iptables não quer dizer nada, você pode ter configurado o iptables na época para fazer um masquerade no IP da LAN do antigo firewall. Portanto o Windows lá do cliente ia ver o RDP vindo da mesma rede, e permitiria o RDP... -
@silence said in NAT com redirecionamento RDP, não funciona.:
disable your firewall in Windows 7 Please
@mcury I suggested this a while back...
