PPTP client not working on 4.10-R
brett at lariat.org
Wed Nov 17 19:32:17 GMT 2004
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.
More information about the freebsd-net