[GTER] Debian PPTPD GRE protocol not available

[Bruno Camargo]

Eu estou no site do cliente hj. E tentei acesso a VPN local, usando o IP de
LAN do servidor 10.1.2.1 e mesmo assim não consegui.

May 11 12:23:39 ddk-lx02 pptpd[1309]: CTRL: Client 192.168.20.103 control
connection started
May 11 12:23:39 ddk-lx02 pptpd[1309]: CTRL: Starting call (launching pppd,
opening GRE)
May 11 12:23:39 ddk-lx02 pppd[1310]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so
loaded.
May 11 12:23:39 ddk-lx02 pppd[1310]: pptpd-logwtmp: $Version$
May 11 12:23:39 ddk-lx02 pppd[1310]: pppd 2.4.5 started by root, uid 0
May 11 12:23:39 ddk-lx02 pppd[1310]: using channel 64
May 11 12:23:39 ddk-lx02 pppd[1310]: Using interface ppp0
May 11 12:23:39 ddk-lx02 pppd[1310]: Connect: ppp0 <--> /dev/pts/1
May 11 12:23:39 ddk-lx02 pppd[1310]: sent [LCP ConfReq id=0x1 <mru 1490>
<asyncmap 0x0> <auth chap MS-v2> <magic 0x3346288e> <pcomp> <accomp>]
May 11 12:23:39 ddk-lx02 pptpd[1309]: GRE: Bad checksum from pppd.
May 11 12:23:39 ddk-lx02 pppd[1310]: rcvd [LCP ConfReq id=0x0 <mru 1400>
<magic 0x1c0a08a1> <pcomp> <accomp> <callback CBCP>]
May 11 12:23:39 ddk-lx02 pppd[1310]: sent [LCP ConfRej id=0x0 <callback
CBCP>]
May 11 12:23:39 ddk-lx02 pptpd[1309]: GRE:
read(fd=7,buffer=608c80,len=8260) from network failed: status = -1 error =
Protocol not available
May 11 12:23:39 ddk-lx02 pptpd[1309]: CTRL: GRE read or PTY write failed
(gre,pty)=(7,6)
May 11 12:23:39 ddk-lx02 pptpd[1309]: CTRL: Reaping child PPP[1310]
May 11 12:23:39 ddk-lx02 pppd[1310]: Hangup (SIGHUP)
May 11 12:23:39 ddk-lx02 pppd[1310]: Modem hangup
May 11 12:23:39 ddk-lx02 pppd[1310]: Connection terminated.
May 11 12:23:39 ddk-lx02 pppd[1310]: Exit.
May 11 12:23:39 ddk-lx02 pptpd[1309]: CTRL: Client 192.168.20.103 control
connection finished

É algo no kernel do Debian squeeze. Acho q foi recentemente feito um
upgrade via apt-get dist-upgrade.

A versão em uso é: 2.6.32-5-amd64

Por isso estou descartando a operadora...

2012/5/11 Michel Souza <micnet21 at gmail.com>

> Bom Dia,
>
> Não precisa, se não me engano; mas oque a operadora pode fazer é filtragem
> dos pacotes, que no caso do GRE é passível. E que além da questão da
> segurança, VPN é um outro produto vendido pelas teles. E no caso acima, o
> erro 619 se refere justamente a bloqueio no roteador de rede ou equipamento
> de internet mais próximo.
>
>
> Abs,
>
> Em 10 de maio de 2012 09:51, Lista <lista.gter at gmail.com> escreveu:
>
> > Bom dia Michel,
> >
> > Mas isso não fica transparente para a operadora, pois ela não precisa
> estar
> > com o modulo ou suporte nos roteadores habilitados, para que ele
> trafegue,
> > seria a mesma coisa que tirar um ipsec do router de borda e mesmo assim a
> > vpn do cliente não pariria de funcionar pq a operadora desabilitou uma
> > feature na borda, ou estou enganado e isso acaba sim refletindo nos
> > clientes? desde que a operadora não faça NAT, é claro!
> >
> > Em 10 de maio de 2012 06:38, Michel Souza <micnet21 at gmail.com> escreveu:
> >
> > > Bruno,
> > >
> > > Um fato importante neste tipo de VPN é que, devido ao GRE ser um
> > protocolo
> > > que emcapsula qualquer outro protocolo; por segurança, nem todas as
> > > operadoras habilitam GRE nos seus roteadores de borda; além de que
> muitos
> > > roteadores/modems xDSL não aceitam GRE. Devido a estas
> > interoperabilidades,
> > > a VPN mais indicada é com a utilização de SSL, como a OpenVPN.
> > >
> > > Neste caso, verifique se o roteador do seu cliente foi substituido e
> se a
> > > operadora de telecom é a mesma que utilizava antes do problema.
> > >
> > >
> > > Att.,
> > >
> > > Michel Souza
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Bruno Camargo