[Resolvido] Dúvida - Acesso RDP | Criação de Regras



  • Boa tarde,
    A alguns dias estou tentando criar 2 regras para acesso ao RDP da empresa, já utilizei vários manuais de referência aqui do fórum e da internet, possuo 2 links de internet configurados no pfSense.

    Segue em anexo um print das regras que criei e das geradas automáticamente.

    Onde estou falhando na criação?
    Verifiquei no yougetsignal e a porta aparece fechado, e o firewall não gera relatórios informando a tentativa de acesso a
    essas portas.

    Obs: Habilitei o pure NAT e as 2 opções que o material de referência informa.
    Desde já agradeço.
    2 links dedicados com IPs fixos
    ![RDP 1.jpg](/public/imported_attachments/1/RDP 1.jpg)
    ![RDP 1.jpg_thumb](/public/imported_attachments/1/RDP 1.jpg_thumb)
    ![RDP 2.jpg](/public/imported_attachments/1/RDP 2.jpg)
    ![RDP 2.jpg_thumb](/public/imported_attachments/1/RDP 2.jpg_thumb)



  • O nat parece ok, já tentou monitorar na console via tcpdump se o trafego chega na lan até o servidor e fica se resposta por exemplo?

    Se isso acontecer, pode ser o firewall do servidor rdp.



  • Boa tarde Marcelloc, obrigado pelo retorno.
    Segue abaixo o comando que utilizei, não tenho muito conhecimento no tcpdump, me corrija se estiver errado:

    Terminal 1: tcpdump -vvv -i bce0 dst 192.168.x.x and port 3389

    Terminal 2: tcpdump -vvv - i bce1 port 3389

    Obs: Anteriormente utilizávamos um firewall baseado em RedHat e o acesso era feito sem problemas, creio que não ser o firewall do WinSRV.



  • Mande um print de suas configurações.



  • Boa noite Danilo,
    Segue em anexo a regra de Portfoward NAT, obrigado pelo retorno.

    ![RDP 1.jpg](/public/imported_attachments/1/RDP 1.jpg)
    ![RDP 1.jpg_thumb](/public/imported_attachments/1/RDP 1.jpg_thumb)
    ![RDP 2.jpg](/public/imported_attachments/1/RDP 2.jpg)
    ![RDP 2.jpg_thumb](/public/imported_attachments/1/RDP 2.jpg_thumb)



  • @z4ratustra:

    Boa tarde Marcelloc, obrigado pelo retorno.
    Segue abaixo o comando que utilizei, não tenho muito conhecimento no tcpdump, me corrija se estiver errado:

    Terminal 1: tcpdump -vvv -i bce0 dst 192.168.x.x and port 3389

    Terminal 2: tcpdump -vvv - i bce1 port 3389

    Obs: Anteriormente utilizávamos um firewall baseado em RedHat e o acesso era feito sem problemas, creio que não ser o firewall do WinSRV.

    Qual foi o resultado do tcpdump?



  • @z4ratustra:

    Terminal 1: tcpdump -vvv -i bce0 dst 192.168.x.x and port 3389

    Terminal 2: tcpdump -vvv - i bce1 port 3389

    Terminal 1: tcpdump -ni bce0 port 3389 and host SEU_IP_PUBLICO_CLIENTE

    Terminal 2: tcpdump -ni bce0 port 3389 and host SEU_IP_PUBLICO_CLIENTE

    pode ser assim também, dessa forma você restringe ao ip externo que está usando para tentar o acesso rdp

    Se o nat estiver ok, você vai ver o trafego chegando na wan e sainda pela lan
    Se só estiver chegando na wan, aí você continua a verificar regras e configurações de nat.



  • @marcelloc:

    @z4ratustra:

    Terminal 1: tcpdump -vvv -i bce0 dst 192.168.x.x and port 3389

    Terminal 2: tcpdump -vvv - i bce1 port 3389

    Terminal 1: tcpdump -ni bce0 port 3389 and host SEU_IP_PUBLICO_CLIENTE

    Terminal 2: tcpdump -ni bce0 port 3389 and host SEU_IP_PUBLICO_CLIENTE

    pode ser assim também, dessa forma você restringe ao ip externo que está usando para tentar o acesso rdp

    Se o nat estiver ok, você vai ver o trafego chegando na wan e sainda pela lan
    Se só estiver chegando na wan, aí você continua a verificar regras e configurações de nat.

    @empbilly:

    @z4ratustra:

    Boa tarde Marcelloc, obrigado pelo retorno.
    Segue abaixo o comando que utilizei, não tenho muito conhecimento no tcpdump, me corrija se estiver errado:

    Terminal 1: tcpdump -vvv -i bce0 dst 192.168.x.x and port 3389

    Terminal 2: tcpdump -vvv - i bce1 port 3389

    Obs: Anteriormente utilizávamos um firewall baseado em RedHat e o acesso era feito sem problemas, creio que não ser o firewall do WinSRV.

    Qual foi o resultado do tcpdump?

    Nenhum resultado em ambos comandos, muito estranho, tenho um PPTP que fiz NAT e rodou certinho, tentei reaproveitar a regra apenas alterando as portas e nada, eu preciso criar alguma regra na LAN? (Se sim desculpem a ignorância.)



  • Se não chega na wan, o problema não está no firewall. Tente um telnet em outra porta até ver o tráfego chegar na wan.



  • Você já tentou alterar a porta do acesso via RDP? Você já viu se o seu Win Server tá habilitado para receber acesso externo via a porta RDP?



  • @marcelloc:

    Se não chega na wan, o problema não está no firewall. Tente um telnet em outra porta até ver o tráfego chegar na wan.

    Bom dia,
    Segue abaixo o relatório do tcpdump que consegui gerar agora pela manhã:

    
    09:45:14.869846 IP (tos 0x0, ttl 114, id 6344, offset 0, flags [DF], proto TCP (6), length 141)
        1x7.xx.xx.xx.3390 > 1x7.x.xx.xx.36131: Flags [P.], cksum 0x5e15 (correct), seq 5633:5734, ack 3145, win 258, length 101
    09:45:14.979009 IP (tos 0x0, ttl 114, id 6345, offset 0, flags [DF], proto TCP (6), length 157)
        1x7.xx.xx.xx.3390 > 1x7.x.xx.xx.36131: Flags [P.], cksum 0x3f94 (correct), seq 5734:5851, ack 3262, win 257, length 117
    09:45:16.166180 IP (tos 0x0, ttl 114, id 6346, offset 0, flags [DF], proto TCP (6), length 52)
        1x7.xx.xx.xx.61854 > 1x7.x.xx.xx.3389: Flags [s], cksum 0xc25f (correct), seq 3424549821, win 8192, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
    09:45:16.166187 IP (tos 0x0, ttl 114, id 6346, offset 0, flags [DF], proto TCP (6), length 52)
        1x7.xx.xx.xx.61854 > 192.168.x.x.3389: Flags [s], cksum 0x54ff (correct), seq 3424549821, win 8192, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
    09:45:22.172121 IP (tos 0x0, ttl 114, id 6359, offset 0, flags [DF], proto TCP (6), length 48)
        1x7.xx.xx.xx.61854 > 1x7.x.xx.xx.3389: Flags [s], cksum 0xd66e (correct), seq 3424549821, win 8192, options [mss 1440,nop,nop,sackOK], length 0
    09:45:22.172127 IP (tos 0x0, ttl 114, id 6359, offset 0, flags [DF], proto TCP (6), length 48)
        1x7.xx.xx.xx.61854 > 192.168.x.x.3389: Flags [s], cksum 0x690e (correct), seq 3424549821, win 8192, options [mss 1440,nop,nop,sackOK], length 0
    
    [quote]
    Você já tentou alterar a porta do acesso via RDP? Você já viu se o seu Win Server tá habilitado para receber acesso externo via a porta RDP?
    [/quote]
    Bom dia,
    Sim, utilizávamos no outro firewall/router, implantamos o pfSense sexta passada. 
    [/s][/s][/s][/s]
    


  • Boa tarde,
    Atualizando mandei gerar log dos IPs com acesso liberado e identifiquei meu endereço tentando acessar o serviço do GLPI sistema de chamados internos e o RDP.
    Obs: Utilizo um serviço de DNS para gerar endereços para os serviços porém mesmo acessando pelo IP da WAN não consigo, ele mostra que está liberado mas não carrega o acesso.

    Porta única

    Descubra o serviço
    Porta Verificar 3389 Aberta ms-wbt-server - MS WBT Server

    ![RDP e GLPI.jpg](/public/imported_attachments/1/RDP e GLPI.jpg)
    ![RDP e GLPI.jpg_thumb](/public/imported_attachments/1/RDP e GLPI.jpg_thumb)



  • O seu dump mostra respostas na 3390, mas parece que para o mesmo ip ou ip na mesma rede.

    A porta 3389 está chegando na wan ou saindo pela lan. Não da pra ter certeza porque você não indicou qual interface monitorou mas o ip de destino é 192.168, que não é comum para uma wan. Repete este teste com outro tcpdump aberto na lan e wan para ver se o tráfego aparece nas duas.



  • @marcelloc:

    O seu dump mostra respostas na 3390, mas parece que para o mesmo ip ou ip na mesma rede.

    A porta 3389 está chegando na wan ou saindo pela lan. Não da pra ter certeza porque você não indicou qual interface monitorou mas o ip de destino é 192.168, que não é comum para uma wan. Repete este teste com outro tcpdump aberto na lan e wan para ver se o tráfego aparece nas duas.

    Marcello, obrigado pela ajuda e paciência, criei uma regra na Lan liberado o acesso ao servidor e adicionei essa regra acima das outras, após isso o acesso foi liberado, creio que me equivoquei na criação, ou não, porque todo o material informa que é só criar o nat e a regra na wan automática, de qualquer forma está funcional.
    Mais uma vez agradeço pela ajuda de todos!



  • De fato a regra é só na interface onde o tráfego começa. Se aquele 192.168 que apareceu na wan for tráfego da lan, pode indicar que você tem problema na sua rede interna.



  • @marcelloc:

    De fato a regra é só na interface onde o tráfego começa. Se aquele 192.168 que apareceu na wan for tráfego da lan, pode indicar que você tem problema na sua rede interna.

    Bom dia Marcello,
    Realmente estou com algum problema de configuração, hoje pela manhã reativei a configuração de failover(multiwan) e as regras pararam de funcionar.
    Creio que dever a regra de multiwan que está barrando os acessos.



  • z4ratustra - eu também já tive uns bugs assim quando tentei coloca failover pela primeira vez. Os Nats não funcionavam, tenta na sua regra da WAN que foi criada automaticamente pelo NAT especificar em Gateway seu GTW1 e cria outra "igual" ( lógico que vai mudar e interface de entrada pra sua WAN2 ) e aponta pro seu GWT2.



  • @ttercio:

    z4ratustra - eu também já tive uns bugs assim quando tentei coloca failover pela primeira vez. Os Nats não funcionavam, tenta na sua regra da WAN que foi criada automaticamente pelo NAT especificar em Gateway seu GTW1 e cria outra "igual" ( lógico que vai mudar e interface de entrada pra sua WAN2 ) e aponta pro seu GWT2.

    Bom dia Ttercio, obrigado pelo retorno.
    Vou criar as regras aqui e validar, assim que possível retorno.



  • Bom dia z4ratustra,

    Já verificou a regra de Firewall do seu Servidor Windows na Opção Publica?

    Faz um teste Rápido. Desativa o firewall  do servidor Windows.



  • Boa tarde,
    Desculpem a demora, não sei por qual motivo a regra da WAN estava sendo bloqueada por outra que estava acima, a regra era de liberação também porém para um host em especifico externo, um "Túnel", após mover as regras de RDP para cima o acesso foi normalizado.
    Agradeço a todos pela ajuda e obrigado pela paciência  ;)