On Fri, 13 Aug 2004, Herron, David S wrote:

> I can't seem to get PPTP to work through m0n0wall.  I am trying to
> connect from a host on my LAN connection to a Windows 2000 VPN server
> outside (WAN) using the XP PPTP client.  If I place my client on the WAN
> subnet (outside the firewall) everything works perfectly.  I am using
> v1.1b16.  I am using captive Portal, everything there works as expected.
> My rules (right now) are set to pass all packets (three rules):

PPTP doesn't work through NAT (without difficulty).  If you don't need to
use m0n0wall's PPTP (client or server) *and* you only need to make
connections from *one* LAN client, then you can do it by setting up "PPTP
redirection".  Yes, that option is meant for servers, but it happens to be
the only way to make clients work as well.

Actually, the outgoing control connection (TCP port 1723) works properly
through NAT as long as multiple clients aren't connecting to the same
server.  But incoming GRE packets need to be redirected properly, and at
present that needs to be done via PPTP redirection, since GRE isn't one of
the selectable protocol types in NAT redirection.

It would be useful (and pretty trivial) to add GRE to the NAT redirection
protocol types, which would add *some* flexibility.  It would be
additionally useful (but less trivial) to add an "other" option, so one
could specify protocols not listed in the popup menu.

With NAT redirection available for GRE, one would *not* use the PPTP
redirection option for clients, but would instead set up NAT mappings as
needed, which could be keyed to the external server IP.  This would not
conflict with incoming PPTP, provided that the same external machine
didn't need to be both a client and a server.

One subtlety here concerns how conflicting NAT mappings are handled, since
there's no provision to adjust the order.  Unless it uses the "most
specific wins" approach, there could be difficulty in having both specific
mappings and general mappings at the same time.

> Client seems to connect, but can't authenticate.  It goes from
> 'Connecting to <vpn host name>' to 'Verifying username and password'.
> It sits there until it times out.  Again, if the client is put on the
> WAN side, the connection goes through perfectly.  M0n0 is being used
> primarily for captive portal support for a campus wireless
> implementation but LAN users on the wireless network (LAN side) will
> need to VPN into corporate network (on other side of another firewall on
> WAN connection) after captive portal allows their login and connection.

Sounds like you're screwed.  If each client only needs to connect to a
*different* server, then the redirection improvement I mentioned above
could be used to configure the proper mappings.  But if you need to have
multiple clients connecting to a *single* server, the only way to make
that work through NAT is with a full-blown PPTP proxy.  The basic problem
is that the NAT code has no means to demultiplex the incoming GRE packets
on any basis other than the IP addresses.

However, if the number of clients is small, and GRE redirection were
available, a possible workaround could be to multihome the server so that
different clients could connect to it at different IPs.  Or multihome the
m0n0wall WAN and use "Advanced outbound NAT" to map the clients to
different WAN IPs.  IOW, insure that at least one of the two external IPs
is different for different clients.

					Fred Wright