On Tue, Dec 22, 2009 at 02:03:37PM +0100, Jelle de Jong wrote:
> James Cameron wrote, on 22-12-09 03:47:
> > My previous postings to this mailing list may also assist.
>
> I read them back starting from a month ago.
http://marc.info/?l=poptop-server&w=2&r=1&s=EPROTO&q=b has a few. I've
just gone back to read some myself.
> It is strange because sometimes the client is just able to connect
> fine, but most time it fails.
That's not strange. I've seen that before. I've especially seen it
when the host running pptpd is slow.
> # this is the outgoing wan interface for the client trying to make a pptp tunnel
> # tcpdump icmp -i eth1 -n -vv
> tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 13:57:49.689674 IP (tos 0xc0, ttl 64, id 44621, offset 0, flags [none], proto ICMP (1), length 89)
> 84.245.1.234 > 188.201.123.45: ICMP 84.245.1.234 protocol 47 unreachable, length 69
> IP (tos 0x0, ttl 53, id 15684, offset 0, flags [DF], proto GRE (47), length 61)
> 188.201.123.45 > 84.245.1.234: GREv1, Flags [key present, sequence# present], call 16384, seq 0, length 41
> LCP, Conf-Request (0x01), id 1, length 27
> encoded length 25 (=Option(s) length 21)
> 0x0000: c021 0101 0019
> ACCM Option (0x02), length 6: 0x00000000
> 0x0000: 0000 0000
> Auth-Prot Option (0x03), length 5: [|lcp]
This shows that host 84.245.1.234 cannot deliver the packet previously
sent by the client (which was 188.201.123.45 > 84.245.1.234 LCP
ConfReq). As a result of not being able to deliver the packet, the host
84.245.1.234 has sent back an ICMP packet.
> # this is the pptp server incomming wan interface
> # tcpdump icmp -i ppp0 -n -vv
> tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
> 13:59:12.593254 IP (tos 0x0, ttl 57, id 44622, offset 0, flags [none], proto ICMP (1), length 89)
> 84.245.1.234 > 188.201.123.45: ICMP 84.245.1.234 protocol 47 unreachable, length 69
> IP (tos 0x0, ttl 53, id 36407, offset 0, flags [DF], proto GRE (47), length 61) 188.201.123.45 > 84.245.1.234: GREv1, Flags [key present, sequence# present], call 32768, seq 0, length 41
> LCP, Conf-Request (0x01), id 1, length 27 [...]
This verifies that the ICMP packet is being created by the pptp server
host. (It is not being synthesised by anything between the hosts, as is
often the case with NAT.)
The usual causes of this are: the host 84.245.1.234 has no process
listening out for protocol 47 packets (e.g. because it did not start the
process in time due to excessive load or misconfiguration),
You may try some workarounds ... [pasting from a previous posting]
1. use an iptables rule on the pptpd host to drop the ICMP Protocol
Unreachable packet altogether, in the hope that the client will begin
negotiation,
2. add the "silent" option to pppd started by pptpd, which will require
the client to begin the negotiation ... this may not work with some
clients.
You may try some further investigation ... using strace on pptpd in
conjunction with tcpdump, discover when the raw socket is created and
connected relative to when the first GRE packet arrives.
--
James Cameron
http://quozl.linux.org.au/
|