On Tue, 1 Jul 2003, Manuel Kasper wrote:
> On Tue, 1 Jul 2003, Serge Leschinsky wrote:
> 
> >  The problem that I have is in the following: one client can connect
> > to PPTP server without any troubles. But the second client can't
> > connect to the same PPTP server (with error "No available port" (or
> > something like that)).
> >
> > Is this a error of my configuration monowall or limitation of current
> > version of firewall or ISP server configuration consequence?
> 
> It's a limitation in ipnat (ipfilter's NAT implementation) in that it does
> not have a custom proxy that understands the details of a GRE tunnel (GRE
> is the protocol PPTP uses to tunnel the actual data). As such, GRE looks
> like a raw IP protocol to ipnat, and since it has no information like
> port numbers (as with TCP/UDP) to distinguish individual connections,
> there can only be one concurrent connection to the same PPTP server. It
> works fine if each of your PPTP clients connects to a different PPTP
> server (i.e. different IP address).
> 
> There has been some discussion about this quite a while ago; the consensus
> was that an ipnat proxy would have to be written that makes use of the
> session ID (or whatever it is called) in the GRE header to distinguish
> individual sessions.

It's actually much worse than that.  Not only do you have to contend with
the GRE traffic, but you have to deal with the TCP-based control
connection, which is only permitted by the protocol to exist once per pair
of endpoints.  There's even a mechanism in the protocol to close one of
the "redundant" connections that could occur if you have a bidirectional
client/server relationship between two machines.  Microsoft tried really
hard to surpass the NAT-unfriendliness of FTP. :-) L2TP is much more
straightforward, but less widely supported.

To support PPTP sessions from multiple clients, you need to map multiple
control connections into a single control connection, and you may need to
remap the Call IDs (and perhaps Call Serial Numbers) to avoid collisions.  
Any remapping of the Call IDs then needs to be applied to the GRE traffic,
in addition to the usual basic NAT handling.

It would be very complicated and perhaps unreliable (due to potentially
inconvenient packet boundaries) to handle the control connection at the
packet level, but since that traffic volume is fairly low it's reasonable
to proxy it at the socket level.  Ideally, the GRE traffic would be
handled at the packet level for efficiency, with the NAT entries
controlled by the proxy.  Since the Call ID doesn't occupy the same
position as either TCP/UDP port number, the NAT code would need special
support for GRE/PPTP.

If *simultaneous* multi-client use (to the same server) isn't needed, a
much simpler kludge would suffice.  The NAT code could just redirect the
GRE packets on the basis of the associated control connection, which by
itself would be an ordinary NAT case.

The other approach is to allow dynamic PPTP sessions from the router
itself, thereby avoiding all the NAT issues.  Though if you don't want to
use NAT on the tunnel, there's the issue of getting the proper routing
entries on the remote end.  Often this requires a static PPTP IP, if it
works at all.

					Fred Wright