Everyone:
I've found what was causing the problems which I reported on net@ and questions@ involving a PPTP client. And I may have uncovered a security problem which -- if my analysis is correct -- should be addressed. (I'd like independent confirmation of this.)
As mentioned in earlier postings, I'd just set up a 4.10-R machine which was to be a PPTP client. (It was using the port of the Linux PPTP client in /usr/ports/net/pptpclient.) It could not connect to a PPTP server on the same LAN, even though that PPTP server was correctly serving other clients -- including Windows machines, FreeBSD machines, and a couple of SOHO routers running embedded Linux.
The problem FINALLY went away after I set the environment variable "gateway_enable" to "YES" in the client's /etc/rc.conf file and rebooted.
The client machine at first seemed to work properly; TCP connections to machines on the local LAN worked correctly. It was when I tried to use the machine as a PPTP client (it was going to tunnel out through the PPTP server to the Internet) that I saw problems -- not only on the client but on the server to which it was trying to connect.
After instrumenting the systems with tcpdump and setting up multiple windows to "tail" all of the logs, I saw what was going on. The PPTP call setup process (which is done via a TCP socket) worked. However, once the initial handshake was complete and the "call" was established, the client's PPP process -- which was supposed to begin LCP negotiations with the server via an encrypted GRE tunnel -- didn't receive any data from the server at all. At the same time, the server's PPP process began to report all sorts of errors.
What happened was that GRE packets received by the client machine were being bounced back, verbatim, to the PPTP server. The PPTP server was mightily confused by this echoing and in fact suffered a partial crash. (Multitudes of messages accumulating in /var/ppp/ppp.log overflowed the PPTP server's /var partition, and some daemons on the machine failed when they couldn't log.) It filled its logs with error messages generated by its own reflected packets -- some whole, some corrupted.
It might be worthwhile to dig a bit into the kernel code and find out why the packets were being reflected, and why the reflection stopped when I turned on packet forwarding. One shouldn't have to enable packet forwarding between interfaces to communicate with a PPTP server on one's local LAN! In fact, it can be a security risk. If you have to enable packet forwarding to establish a VPN connection, you might inadvertently open up a back door from the Internet at large to the private network which you're accessing via the VPN.
Because this is a security concern, I'm posting this message to security@ as well as the two lists where I posted originally. But I'm BCC'ing all three to prevent responses from being cross-posted.
--Brett Glass
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
