On Wed, 30 Jun 2004, Michael Iedema wrote:
> The VPN at my work place has been in place for ~6 months with nearly no
> trouble. Today, however, was a different story.
> I received a phone call saying that a client could not connect and I
> checked out the system logs to find:
> The post outlining the same error message is at:
> In it Adam Hirsch discovers that the culprit is the NAT implementation
> at his work place. I would place the blame here as well except that
> this client is behind a m0n0wall and has had no problems connecting before.
In general, PPTP does not work properly through NAT, except:
1) In very limited cases, usually requiring an explicit redirection.
"Limited cases" means (at best) no more than one internal PPTP endpoint
per external endpoint, regardless of whether it's a client or server. It
only works without redirection if the LAN side is the client *and* sends
the first packet in the GRE exchange. A relatively simple NAT hack could
eliminate the need for explicit redirection, although it wouldn't remove
the 1:1 internal/external limitaion.
2) With some sophisticated code on the NAT router to proxy the control
connections, remap the call IDs, and appropriately remap and redirect the
On a somehwat related note, I don't recall hearing that m0n0wall has ever
fixed the conflict between client and server PPTP. In other words,
m0n0wall can't act as a PPTP server if it needs to use PPTP to connect to
a modem. I suspect that this *can* work, but would require combining the
client and server operations into a single instance of MPD, because trying
to run two copies runs into a conflict mandated by the protocol.