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:
> http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=50&actionargs[]=12
> 
> 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
GRE packets.

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.

					Fred Wright