[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] how to set up a the PPTP server with firewall rules
 Date:  Mon, 7 Jul 2003 04:25:49 -0700 (PDT)
On Mon, 7 Jul 2003, Manuel Kasper wrote:
> On Sun, 6 Jul 2003, Fred Wright wrote:
> > Only the GRE traffic is a problem, since there's no conflict with the
> > control connection (as long as you don't need simultaneous client and
> > server operation with respect to a single remote system).  So the PPTP
> > code should be able to use the local IP address of the already-established
> > control connection socket to bind() the (presumably raw) GRE socket.  It
> > could even bind to the remote IP by using connect(), which also improves
> > efficiency.
> Interestingly, the reason for the "Address already in use" message is not
> GRE, but the TCP port 1723 server socket. I sent Michiel a slightly

That's bizarre, unless the PPTP client is actually attempting to implement
the shared client/server control connection, perhaps in a non-useful
way.  Otherwise, there's no reason why the client would use *local* port
1723 at all.

Or are multiple server-side instances getting started?

> modified version of m0n0wall where the PPTP server uses "set pptp self"
> (to like the PPTP client does (which uses the pseudo WAN IP

What's it trying to do with loopback?  A connection bound to that IP
couldn't leave the box.

> address assigned on the WAN->PPTP setup page). Still - the same message...
> Looking at MPD's source code, it's clear that the message originates from
> the bind() on the TCP server socket. I don't quite understand why two
> different processes cannot bind to the same port but on different IP
> addresses... I thought that was possible. MPD even uses setsockopt(...

It's possible if you use SO_REUSEADDR.

> SO_REUSEADDR ...) before the bind() - don't know what effect that has,
> though.

It definitely needs that if it's using a fixed port locally.  Without
SO_REUSEADDR, it's not even possible to bind a listener to a port when a
*connection* exists involving that same local port, let alone another
listener.  Part of the problem is that there's no way to atomically bind a
socket to both local and remote addresses, since two separate calls are

> Some more debugging may be in order, I guess. Maybe we have to check if
> MPD really supplies the IP address given in "set pptp self" to bind().

A good start would be to look with netstat while the client side is

					Fred Wright