Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [Resolvido] VNC conecta mas RDP não

    Scheduled Pinned Locked Moved Portuguese
    11 Posts 3 Posters 2.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • adrianomirandaA Offline
      adrianomiranda
      last edited by

      Olá pessoal, pesquisei muito estes últimos dias aqui no fórum e não vi nada parecido com este caso em específico.

      Estou ainda testando o PFSense na empresa em que trabalho e não consigo acessar um servidor via RDP. Vou mostrar meu cenário e utilizar as portas padrões depois pretendo alterar a porta padrão do MS RDP para obter mais segurança. Mas vamos lá:

      Temos um outro FW que é terceirizado por conter alguns outros serviços, mas que eu quero desativa-lo e utilizar apenas o PFSense com dois links de internet e balancear para rede interna.

      Minhas regras (ocultei os IPS em "Destination" mas correspondem ao IP interno do meu servidor):

      O que acontece: Na rede interna consigo acessar o servidor via RDP normalmente. De fora entrando pelo PFSense não consigo. Já alterei o GTW do servidor para que seja o PFSense mas também não funcionou.

      Já via VNC nas portas 5900 e 5800 acesso normalmente da forma como está agora.

      Alguém tem alguma sugestão?

      Obrigado!

      1 Reply Last reply Reply Quote 0
      • L Offline
        LFCavalcanti
        last edited by

        Olá!

        Primeiro, uma dica se segurança:
        Trocar a porta padrão do MS-RDP na regra de NAT não aumenta nada em segurança. O melhor é acessar via VPN mesmo.

        Sobre o seu problema:
        A regra NAT parece estar em ordem, então o problema pode estar no Servidor em questão. Verifique se o Terminal Service está ativado e se não há algum bloqueio de Firewall local.

        –

        Luiz Fernando Cavalcanti
        IT Manager
        Arriviera Technology Group

        1 Reply Last reply Reply Quote 0
        • adrianomirandaA Offline
          adrianomiranda
          last edited by

          Obrigado pela dica.

          Mas de qualquer forma, este servidor também será acessado por um DBA externo e eu penso que fica mais comodo de certa forma. Sem que ele precise conectar a VPN sempre que precisar alterar alguma coisa no BD. Então a principio farei uma mudança tanto no server quanto no NAT alterando a porta padrão. Mas enfim…

          1. O terminal service está ativado sim e como eu disse, acesso internamente sem problemas;

          2. O firewall do servidor está desabilitado.

          1 Reply Last reply Reply Quote 0
          • marcellocM Offline
            marcelloc
            last edited by

            Hora de rodar o tcpdump na console/ssh para ver onde os pacotes estão parando.

            Treinamentos de Elite: http://sys-squad.com

            Help a community developer! ;D

            1 Reply Last reply Reply Quote 0
            • adrianomirandaA Offline
              adrianomiranda
              last edited by

              @marcelloc:

              Hora de rodar o tcpdump na console/ssh para ver onde os pacotes estão parando.

              @marcelloc no meu caso, a interface é "WAN_OI" então eu devo rodar o comando desta forma: tcpdump -i wan_oi dst port 3389 ?

              1 Reply Last reply Reply Quote 0
              • marcellocM Offline
                marcelloc
                last edited by

                Na wan e na lan para saber o que está acontecendo com os pacotes.

                Treinamentos de Elite: http://sys-squad.com

                Help a community developer! ;D

                1 Reply Last reply Reply Quote 0
                • adrianomirandaA Offline
                  adrianomiranda
                  last edited by

                  @marcelloc, rodei o tcpdump só não entendi o resultado.

                  Olha só:

                  WAN: tcpdump -ni wan dst port 3389

                  14:22:43.196514 IP 189.xxx.xxx.xx.57854 > 201.xxx.xxx.xxx.3389: Flags ~~, seq 978402836, win 8192, options [mss 1460,nop,nop,sackOK], length 0

                  LAN: tcpdump -ni lan port 3389

                  14:22:43.196546 IP 189.xxx.xxx.xx.57854 > ip_do_servidor.3389: Flags , seq 978402836, win 8192, options [mss 1460,nop,nop,sackOK], length 0~~

                  1 Reply Last reply Reply Quote 0
                  • marcellocM Offline
                    marcelloc
                    last edited by

                    mude o dst port por port.

                    você só pegou os pacotes entrando.

                    Já da para adiantar que o pacote está chegando no servidor rdp.

                    Treinamentos de Elite: http://sys-squad.com

                    Help a community developer! ;D

                    1 Reply Last reply Reply Quote 0
                    • adrianomirandaA Offline
                      adrianomiranda
                      last edited by

                      Beleza, o resultado foi o mesmo:

                      WAN: tcpdump -ni re1 port 3389
                      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                      listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
                      16:15:53.124079 IP 189.XXX.XXX.XXX.51275 > 201.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0
                      16:15:56.125996 IP 189.XXX.XXX.XXX.51275 > 201.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0
                      16:16:02.119732 IP 189.XXX.XXX.XXX.51275 > 201.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0

                      LAN: tcpdump -ni re0 port 3389
                      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                      listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
                      16:15:53.124112 IP 189.XXX.XXX.XXX.51275 > 192.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0
                      16:15:56.126007 IP 189.XXX.XXX.XXX.51275 > 192.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0
                      16:16:02.119746 IP 189.XXX.XXX.XXX.51275 > 192.XXX.XXX.XXX.3389: Flags ~~, seq 1998778755, win 8192, options [mss 1460,nop,nop,sackOK], length 0

                      Já tentei também direcionando para outras estações da rede interna além deste servidor.~~~~~~~~~~~~

                      1 Reply Last reply Reply Quote 0
                      • marcellocM Offline
                        marcelloc
                        last edited by

                        O pacote vai para o servidor mas não volta.

                        Não é problema no pfsense.

                        Veja se não é o firewall do windows.

                        Treinamentos de Elite: http://sys-squad.com

                        Help a community developer! ;D

                        1 Reply Last reply Reply Quote 0
                        • adrianomirandaA Offline
                          adrianomiranda
                          last edited by

                          @marcelloc muito obrigado pela ajuda, o firewall do windows estava desativado mas o Kaspersky também tem um firewall que tava bloqueando o retorno dos pacotes.

                          Criei uma regra no Firewall do Kaspersky e resolvido.

                          E um detalhe que eu não achava necessário: O gateway do pc interno que está recebendo a conexão RPD tem que estar configurado apontando para o meu servidor que recebe a conexão de entrada da internet (na imagem do primeiro post desse tópico seria o PFSense 10.0.0.1).

                          Obrigado a todos pelas dicas, espero que este post possa ajudar alguém no futuro!

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.