On Thu, Feb 17, 2005 at 08:11:07AM -0600, Josh Close wrote:
> On Thu, 17 Feb 2005 11:24:11 +1100, James Cameron <james.cameron@...> wrote:
> > [...]
> > This shows that despite negotiating 128-bit stateless encryption without
> > compression, the peer began to communicate in a form that was not
> > recognised.
>
> Do you think this might have something to do with my ppp configuration?
Yes, the negotiation and packet handling at this stage is exclusively
within the PPP configuration, both the pppd binary and the kernel PPP
modules. Your problem is purely a PPP problem. It's just that it's
happening in the context of a PPTP connection.
> > What variant of pppd are you using?
> Here is the info on the package I have installed.
> Latest version available: 2.4.2-r10
Try 2.4.3 from http://www.samba.org/ppp or Jan Dubiec's fork.
> This is the version of pptpclient.
Unimportant but interesting; the problem doesn't have anything to do
with PPTP at this stage. You're using 1.3.1, but 1.5.0 is the latest
version; and 1.6.0 is about to be released.
> > Can you tell us anything about the peer?
> What would you like to know about the peer? It's running Gentoo Linux.
> I have the kernel patched with the patch located here:
> http://pptpclient.sourceforge.net/mppe/. The kernel I'm using is
> linux-2.6.9-gentoo-r1. It's the 2.6.9 with gentoo patches. What else
> would you like to know?
Version of pppd and kernel PPP support on the peer would be interesting.
Is it 64-bit architecture or 32-bit? We had some problems at one stage
with the crypto code on 64-bit.
> Do you need the file before it was converted into plain text?
Yes, but given that you have control over the peer (?) perhaps I won't
really need it. Let's see the outcome of comparing the pppd
implementations thoroughly.
> won't there be sensitive info in there?
Yes, there will. At least IP addresses, usernames and
challenge-response form of the passwords. No plain-text passwords
(unless the tunnel worked and you ran an FTP or non-SSL POP3 query).
If the IP address is public, and someone wants to spend the time to
brute force the crypto exchange, they could gain entry to the VPN
server. Same risks as if they were able to listen on your network
links. If you change the password after making the tcpdump, then
there's much less risk of successful entry.
Up to you to decide the risk and the level of trust you have in me and
HP. Because I'm using HP's sponsorship of this project to deal with
you, any existing contract you have with HP for software support would
likely apply in terms of information security and privacy. We have
standards of business conduct that I must apply; and these include
privacy of information; even if the work is done on a volunteer basis.
I can take GnuPG encrypted mail, or symmetric crypto if you send me the
passphrase out of band (e.g. by telephone).
By the way, the change to the module list in your subsequent post should
have no impact on this particular problem. It only changes how the
module is loaded when probed for by PPP. If the module couldn't be
loaded, you'd be getting the "kernel has no support" message.
--
James Cameron http://quozl.netrek.org/
HP Open Source, Volunteer http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
|