On Fri, 2004-01-30 at 08:18, Grant Parnell wrote: > On Thu, 29 Jan 2004, Peter Rundle wrote: > > > Trying to connect from my Linux desktop to a remote Linux server running > > pptpd fails with > > this error in the remote linux servers syslog; > > > > pptpd[21127]: CTRL: Client 61.95.85.130 control connection started > > pptpd[21127]: CTRL: Starting call (launching pppd, opening GRE) > > pppd[21128]: pppd 2.4.1 started by root, uid 0 > > pppd[21128]: Using interface ppp0 > > pppd[21128]: Connect: ppp0 <--> /dev/pts/1 > > pptpd[21127]: GRE: xmit failed from decaps_hdlc: Operation not permitted > > pptpd[21127]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6) > > > > Google tells me this error is caused by the firewall blocking GRE, so I > > temporarily dropped the > > firewall on the remote pptpd server;
Have you explicitly allowed GRE, with something like iptables -A INPUT -p 47 -j ACCEPT ? > -- snip -- > > But no joy, I still get the same error. > > > > My desktop can connect to another remote Linux pptpd server no problems, > > and I've compared the > > /etc/ppp/pptpd.conf and /etc/ppp/pptpd.options files on the two servers > > and both are the same > > (tcpip addresses not withstanding). > > > > Any cluesticks? > > Only that the GRE packets may be blocked elsewhere, ie ISP's have been > known to block. Maybe there's a utility like tcpdump that will show GRE > packets. On the server, tcpdumping all traffic from the client IP should show GRE, if it's getting through. Likewise a tcpdump on the client should show outbound GRE. Compare and contrast the two. :-) Note that (AFAIK) you can't specify the GRE protocol in a tcpdump filter, so the best way to do it would probably be to show all traffic from the appropriate IP address (with the notable exception of port 22 if you're logging in remotely :-) -- Pete -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
