VPN PPTP
-
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?
-
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
-
-
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 internet3 - 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)
-
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.
-
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 -
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!
JackOi 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.71pfSense 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 kerneltcpdump 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> -
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
-
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. -
Eu desisti do PPTP, configurei o openvpn e tudo funciona! O problema é q o iOS Não tem cliente openvpn!
-
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.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
