[pptp-server] Problem connecting over Dialup connection

[Patrick J. LoPresti]

"Jason M. Felice" <jasonf at Baldwingroup.COM> writes:

> This makes me very curious as to how PoPToP handles gre packets
> which get sliced up (due to device MTU or what not).

PoPToP never knows about it.  pptpd uses a raw socket to read and
write GRE packets, so it never sees fragments (nor even knows when
fragmentation happened).

> Changing the MTU to be lower on the server won't change anything, BTW, 
> neither will changing the MTU on the client (can you do that under
> Windoze).

I think it will (and tests here suggest that it does).  The PPP
connection is tunnelled over GRE, but the code sending packets into
the PPP device doesn't know that.  So the MTU on the server will
affect whether packets get fragmented as they make their way into the
tunnel.

> Changing the MTU on an intermediary router is the only thing you can
> do to cause packets to get sliced.  Even then, I'm not sure if route
> MTU discovery (via some ICMP magic) is involved.

Whether path MTU discovery is being used depends on the protocol
(e.g., TCP) and implementation.  It works by setting the "don't
fragment" bit on the IP packets and then processing the resulting ICMP
responses.  (At least, that is my understanding; I am sure someone
will correct me if I am confused.)

Of course, the "don't fragment" bit is buried in the GRE
encapsulation, so PPTP completely defeats the whole purpose of path
MTU discovery.

> If it is, this is sometimes incorrect as some firewall vendors
> filter these ICMP requests and others (for some reason) always reply
> 1500, despite the actual MTU.

Not exactly; the firewalls swallow the ICP responses, making path MTU
discovery fail.  David Luyer (one of the PoPToP developers, and much
more of an expert than I) says most everyone just assumes a MTU of
1500.  Of course, GRE adds an overhead of 12 to 16 bytes, so even that
assumption is pretty meaningless.

I still suspect it might make sense to drop the mtu a bit to make room
for the GRE overhead, but I have no empirical evidence to support
this.

 - Pat