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

    VPN PPTP

    Portuguese
    5
    12
    11.7k
    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.
    • A
      andre.andrade
      last edited by

      Boa noite.

      estou com um problema com conexão PPTP eu instalei um Pfsense 1.2.3 e configurei a opção PPTP nesse servidor ele esta configurado para ser um Servidor PPTP para que os funcionarios possam se conectar na rede quando estão fora da empresa mas existem momentos que eu preciso me conectar em outro cliente por PPTP mas ele não conecta da erro na autenticação ja criei a regra para liberar a porta PPTP porta 1723 na wan eu liberei o protocolo GRE mas não consigo comectar da empresa para outro cliente, se eu desabilito a opção de servidor PPTP eu conecto normalmente alguem poderia me ajudar?

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

        Voce já testou esta mesma configuração com o pfsense 2?

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

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • T
          thiago.limax64
          last edited by

          Complementando o problema reportado pelo nosso amigo André…

          O PFSense esta com as regras de firewall devidamente configuradas: 1723 e GRE; Source "LAN Net" e Destionation "*".

          Teste de telnet está ok na Porta 1723 para meu destino quando estou atras do pfsense mas ao conectar fica na tela "Verifyng username and password" e depois da o erro: 619 (Lembrando que GRE está liberado)

          Vi que várias pessoas na comunidade estão com o mesmo problemas e as respostas não são conslusivas...

          Instalei o PFSense 2.0 imaginando que o problemas estivesse corrigido mas nada.

          Parece que o erro só ocorre quando configuro meu servidor PFSense como pptp server... quando não tenho o serviço de VPN Server configurado no PFSense a conexao vai normalmente.

          Se trata de alguma limitação do PFSense? Algo haver com limitações do NAT?

          1 Reply Last reply Reply Quote 0
          • JackLJ
            JackL
            last edited by

            @Thiago:

            Complementando o problema reportado pelo nosso amigo André…
            O PFSense esta com as regras de firewall devidamente configuradas: 1723 e GRE; Source "LAN Net" e Destionation "*".
            Teste de telnet está ok na Porta 1723 para meu destino quando estou atras do pfsense mas ao conectar fica na tela "Verifyng username and password" e depois da o erro: 619 (Lembrando que GRE está liberado)
            Vi que várias pessoas na comunidade estão com o mesmo problemas e as respostas não são conslusivas...
            Instalei o PFSense 2.0 imaginando que o problemas estivesse corrigido mas nada.
            Parece que o erro só ocorre quando configuro meu servidor PFSense como pptp server... quando não tenho o serviço de VPN Server configurado no PFSense a conexao vai normalmente.
            Se trata de alguma limitação do PFSense? Algo haver com limitações do NAT?

            Buenas!

            @Thiago L Oliveira,

            Não há problema algum com o serviço PPTP do PFSense. Neste seu cenário, tente conferir os seguintes aspectos:

            • Se você está utilizando o "discador" do Windows nos clientes, certifique-se que a guia "Segurança" esteja igual a que segue em anexo neste post;

            • Se você não quer que os clientes utilizem sua rede VPN para navegar na web, tenha certeza de que a respectiva opção esteja desmarcada (veja pptp_avancada.jpg);

            • Verifique se em "Firewall->Rules->PPTP VPN" você tem uma regra liberando em todos os sentidos a comunicação entre os clientes VPN e o restante da tua rede;

            • Se você quer compartilhar impressora e outros devices entre sua LAN e seus clientes PPTP, certifique-se de liberar em  "Firewall->Rules->LAN" todas as conexões vindas de clientes PPTP.

            Abraços!
            Jack

            pptp_avancada.jpg
            pptp_avancada.jpg_thumb
            pptp_seguranca.jpg
            pptp_seguranca.jpg_thumb

            Treinamentos de Elite: http://sys-squad.com
            Soluções: https://conexti.com.br

            1 Reply Last reply Reply Quote 0
            • T
              thiago.limax64
              last edited by

              OI Jack.. obrigado pela dica mas acho que voce nao entendeu a gravidade do problema :)

              Vamos ao cenário….

              1 - Nosso PFSense esta configurado como PPTP Server e firewall de borda e nossa equipe acessa nossa vpn sem problemas (não é esse o problema)

              2 - Precisamos acessar a VPN de um cliente que tem um firewall da Dlink com pptp server configurado e é aí que o erro ocorre (erro 619)
              2.1 - As regras do PFSense estão liberando nossa LAN Net para acessar todos os protocolos e portas desse cliente (ip publico fixo)
              2.2 - Fechamos telnet na porta 1723 sem problemas e GRE esta liberado da LAN Net para internet

              3 - Quando desativamos o PPTP Server do nosso PFSense a conexão com a VPN desse cliente (Firewall Dlink) conecta sem problemas

              4 - Quando acessamos a VPN desse cliente (Firewall Dlink) por fora do PFSense, conseguimos conexao sem problemas (logo tambem nao é problema no nosso cliente)

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

                Se a sua suspeita é que o pfsense esta fazendo algum tipo de Forward desta conexão para o servidor local, Voce pode tentar criar uma regra na lan(onde seu computador deve estar) liberando trafego para o ip desse dlink forcando o gateway da sua wan.

                Monitore via tcpdump na console para onde os pacotes estão indo.

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

                Help a community developer! ;D

                1 Reply Last reply Reply Quote 0
                • JackLJ
                  JackL
                  last edited by

                  @marcelloc:

                  Se a sua suspeita é que o pfsense esta fazendo algum tipo de Forward desta conexão para o servidor local, Voce pode tentar criar uma regra na lan(onde seu computador deve estar) liberando trafego para o ip desse dlink forcando o gateway da sua wan.
                  Monitore via tcpdump na console para onde os pacotes estão indo.

                  @Thiago L Oliveira,

                  Uma dica adicional ao que o colega @marcelloc lhe repassou, é fazer com que esta regra que libera (irrestritamente e com gateway fixo) o acesso ao seu cliente (Dlink), em "Firewall->Rules-Lan", fique encabeçada (se possível seja a primeira regra). Como o firewall sempre é interpretado sequencialmente, assim você terá certeza que a priori não há bloqueio ou resposta local da conexão PPTP.

                  Faça um teste (o tcpdump também é uma execlente pedida, conforme dica do @marcelloc) e poste aqui qualquer resultado.

                  Abraços!
                  Jack

                  Treinamentos de Elite: http://sys-squad.com
                  Soluções: https://conexti.com.br

                  1 Reply Last reply Reply Quote 0
                  • T
                    thiago.limax64
                    last edited by

                    @JackL:

                    @marcelloc:

                    Se a sua suspeita é que o pfsense esta fazendo algum tipo de Forward desta conexão para o servidor local, Voce pode tentar criar uma regra na lan(onde seu computador deve estar) liberando trafego para o ip desse dlink forcando o gateway da sua wan.
                    Monitore via tcpdump na console para onde os pacotes estão indo.

                    @Thiago L Oliveira,

                    Uma dica adicional ao que o colega @marcelloc lhe repassou, é fazer com que esta regra que libera (irrestritamente e com gateway fixo) o acesso ao seu cliente (Dlink), em "Firewall->Rules-Lan", fique encabeçada (se possível seja a primeira regra). Como o firewall sempre é interpretado sequencialmente, assim você terá certeza que a priori não há bloqueio ou resposta local da conexão PPTP.

                    Faça um teste (o tcpdump também é uma execlente pedida, conforme dica do @marcelloc) e poste aqui qualquer resultado.

                    Abraços!
                    Jack

                    Oi Jack e Marcello,

                    Obrigado pelas dicas tudo isso já foi feito :).

                    Segue os resultados:
                    1 - Sim a regra é a primeira da minha lan (cima para baixo) liberando todo trafego:
                    Proto * | Source IP_DO_CLIENTE_PPTP | Port * | Destination IP_VPNSERVER_DLINK | Port * | GTW * (só tenho um gtw de internet) |

                    2 - no momento exato da tentativa de conexao até ocorrer o erro 619

                    login as: admin
                    Using keyboard-interactive authentication.
                    Password:

                    *** Welcome to pfSense 2.0-RELEASE-pfSense on server01 ***

                    LAN*                    ->  bge0    ->      192.168.10.200
                      WAN*                    ->  xl0    ->      171.91.158.71

                    pfSense console setup


                    0)  Logout (SSH only)
                    1)  Assign Interfaces
                    2)  Set LAN IP address
                    3)  Reset webConfigurator password
                    4)  Reset to factory defaults
                    5)  Reboot system
                    6)  Halt system
                    7)  Ping host
                    8)  Shell
                    9)  PFtop
                    10)  Filter Logs
                    11)  Restart webConfigurator
                    12)  pfSense Developer Shell
                    13)  Upgrade from console
                    14)  Disable Secure Shell (sshd)

                    Enter an option: 8

                    tcpdump dst 186.251.100.22

                    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                    listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes
                    15:56:29.900351 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: S 3729238585:3729238585(0) win 65535 <mss 1460,nop,nop,sackok="">15:56:29.963035 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: . ack 2260619282 win 65535
                    15:56:29.963192 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: P 0:156(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(3790) [|pptp]
                    15:56:29.999070 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: P 156:324(168) ack 157 win 65379: pptp CTRL_MSGTYPE=OCRQ CALL_ID(39707) CALL_SER_NUM(21) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) [|pptp]
                    15:56:30.036526 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: P 324:348(24) ack 189 win 65347: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(0) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
                    15:56:30.039393 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
                    15:56:32.027155 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23
                    15:56:35.027221 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 2, length 37: LCP, Conf-Request (0x01), id 2, length 23
                    15:56:39.027035 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 3, length 37: LCP, Conf-Request (0x01), id 3, length 23
                    15:56:43.027016 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 4, length 37: LCP, Conf-Request (0x01), id 4, length 23
                    15:56:47.027097 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 5, length 37: LCP, Conf-Request (0x01), id 5, length 23
                    15:56:51.027069 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 6, length 37: LCP, Conf-Request (0x01), id 6, length 23
                    15:56:55.026988 IP 192.168.10.144 > firewall-dlink34.stb.gvt.net.br: GREv1, call 0, seq 7, length 37: LCP, Conf-Request (0x01), id 7, length 23
                    15:56:57.224647 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: P 348:364(16) ack 337 win 65199: pptp CTRL_MSGTYPE=StopCCRQ REASON(1)
                    15:56:57.274712 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: F 364:364(0) ack 353 win 65183
                    15:56:57.274736 IP 192.168.10.144.3430 > firewall-dlink34.stb.gvt.net.br.pptp: . ack 354 win 65183
                    ^C
                    16 packets captured
                    19102 packets received by filter
                    0 packets dropped by kernel

                    tcpdump src 186.251.100.22

                    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                    listening on bge0, link-type EN10MB (Ethernet), capture size 96 bytes
                    15:57:57.322482 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: S 1365569720:1365569720(0) ack 372036151 win 32768 <mss 1452="">15:57:57.359944 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: P 1:157(156) ack 157 win 32612: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(1) [|pptp]
                    15:57:57.359976 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: . ack 157 win 32612
                    15:57:57.391188 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: P 157:189(32) ack 325 win 32444: pptp CTRL_MSGTYPE=OCRP CALL_ID(0) PEER_CALL_ID(30978) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(128) PROC_DELAY(0) PHY_CHAN_ID(0)
                    15:57:57.391290 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: . ack 325 win 32444
                    15:57:57.423277 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: . ack 349 win 32420
                    15:58:24.573802 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: P 189:337(148) ack 349 win 32420: pptp CTRL_MSGTYPE=CDN CALL_ID(0) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) [|pptp]
                    15:58:24.606980 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: P 337:353(16) ack 365 win 32404: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0)
                    15:58:24.607673 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: F 353:353(0) ack 365 win 32404
                    15:58:24.635037 IP firewall-dlink34.stb.gvt.net.br.pptp > 192.168.10.144.3438: . ack 366 win 32403
                    ^C
                    10 packets captured
                    10520 packets received by filter
                    0 packets dropped by kernel
                    #</mss></mss>

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

                      mesmo com um gateway soh, marque ele.

                      os pacotes gre nao esto voltando, veja o tcpdump pela interface

                      lan e wan

                      primerio na lan

                      tcpdump -ni xl0 host 186.251.100.22

                      veja o que acontece

                      depois na wan

                      tcpdump -ni bge0 host 186.251.100.22

                      na wan, o seu ip tem que aparecer depois de fazer o nat.

                      o gw na regra, vai forcar o pacote a sair pela interface em vez de sair pela tabela de roteamento.

                      confere se no outbound nat, voce colocou qualquer protocolo, afinal GRE nao eh TCP

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

                      Help a community developer! ;D

                      1 Reply Last reply Reply Quote 0
                      • A
                        andre.andrade
                        last edited by

                        Boa noite…
                        Thiago
                        Hoje eu estava fazendo mais alguns testes com conexão PPTP para o outro cliente, o meu pfsense esta configurado como servidor PPTP, quando eu tentei conectar no cliente ele conectou na primeira tentativa consegui fechar a VPN mas ao desconectar a vpn e tentar novamente ocorreio o erro 619 ficou tentando autenticar mas não foi.

                        1 Reply Last reply Reply Quote 0
                        • K
                          klamath
                          last edited by

                          Eu desisti do PPTP, configurei o openvpn e tudo funciona! O problema é q o iOS Não tem cliente openvpn!

                          HP ProLiant MicroServer N40L - 2GB - 250G HD - 3 NIC Intel PRO/1000 MT Gigabit PCI
                          pfSense 2.0.1-RELEASE (amd64)

                          1 Reply Last reply Reply Quote 0
                          • JackLJ
                            JackL
                            last edited by

                            @andre.andrade:

                            Boa noite…
                            Thiago
                            Hoje eu estava fazendo mais alguns testes com conexão PPTP para o outro cliente, o meu pfsense esta configurado como servidor PPTP, quando eu tentei conectar no cliente ele conectou na primeira tentativa consegui fechar a VPN mas ao desconectar a vpn e tentar novamente ocorreio o erro 619 ficou tentando autenticar mas não foi.

                            @andre.andrade,

                            Atenção: Até onde eu testei, dois clientes PPTP não podem conectar a partir de um mesmo IP de origem, ou seja, se você está tentando conectar duas máquinas clientes simultaneamente no seu servidor PPTP, pelo mesmo IP público (conexão nateada), a segunda não vai conseguir conexão. Talvez este seja o seu cenário/problema!!!

                            Não sei se outros colegas aqui do fórum possuem alguma outra impressão a este respeito ou conhecem algum "atalho" que permita contornar esta imposição?!??

                            Abraços!
                            Jack

                            Treinamentos de Elite: http://sys-squad.com
                            Soluções: https://conexti.com.br

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