asked on

pptpd with linux weird behaviour

Hi guys

I'm trying to configure pptpd to work with linux (slackware). The funny thing is that I'm connecting from
Windows XP to VPN server using any login name and any password (when checkbox "disconnect if no encryption" unchecked) i can connect without any problems , moreover when I check checkbox ("disconnect if no encryption") in vpn settings of windows Xp while connecting i get message that local computer doesen't use this kind of encryption . It's weird 'cause Windows Xp suppose to use MS-CHAP v2 (mppe) encryption. If you have any ideas please let me know.

I will post some conf files to make things clear

/etc/pptpd.conf :
--------------------------
# TAG: speed
# Specifies the speed for the PPP daemon to talk at.
#speed 115200

# TAG: option
# Specifies the location of the PPP options file.
# By default PPP looks in '/etc/ppp/options'
#option /etc/ppp/options.pptpd
localip 192.168.5.1
remoteip 192.168.5.5-15
# TAG: pidfile
# Determines where pptpd writes its pid
pidfile /var/run/pptpd.pid
--------------------------

/etc/ppp/options.pptpd:

-------------------------------
# This file should work for Win9x and NT clients but as always
# your mileage may vary. Always consult the documentation.
lock
mtu 1450
mru 1450
debug
Auth
-detach
proxyarp
asyncmap 0
require-chap
require-mppe-128
require-mschap-v2
require-mppe-stateless
-chap
-chapms
+chapms-v2
ipcp-accept-local
ipcp-accept-remote
lcp-echo-failure 30
lcp-echo-interval 5
mppe-128
mppe-stateless
-------------------------------------------------------

tail /var/log/messages :

-----------------------------------------

Apr 25 23:22:36 slack pptpd[1613]: CTRL: Client 192.168.5.2 control connection started
Apr 25 23:22:36 slack pptpd[1613]: CTRL: Starting call (launching pppd, opening GRE)
Apr 25 23:22:36 slack pppd[1614]: pppd 2.4.0b4 started by root, uid 0
Apr 25 23:22:36 slack pppd[1614]: Using interface ppp0
Apr 25 23:22:36 slack pppd[1614]: Connect: ppp0 <--> /dev/pts/1
Apr 25 23:22:36 slack pppd[1614]: LCP terminated by peer (6sXM-^W^@<M-Mt^@^@^BM-e)
Apr 25 23:22:36 slack pppd[1614]: Modem hangup
Apr 25 23:22:36 slack pppd[1614]: Connection terminated.
Apr 25 23:22:36 slack pppd[1614]: Exit.
Apr 25 23:22:36 slack pptpd[1613]: CTRL: Client 192.168.5.2 control connection finished
------------------------------------------------------------------------------------

tail /var/log/syslog :
----------------------------------
Apr 25 23:17:56 slack pptpd[1533]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Apr 25 23:20:28 slack pptpd[1553]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Apr 25 23:21:31 slack pptpd[1573]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Apr 25 23:21:36 slack pptpd[1593]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Apr 25 23:22:36 slack pptpd[1613]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
--------------------------------------------------

Regards

P.S. If you know any site how to force linux slackware to work properly with pptpd please let me know if possible as well

pjedmond

I've done a couple of this type of thing, but with a RHEL server, never slackware, so I'm not really 100% familiar with the set up.

Generally, the bit that people fail to do is ensure that they get the correct match for the kernel and pppd This is because the mppe needs to be compiled with the kernel (either included, or as a module).

Assuming that you've done that bit correctly, the secong *really* irritating issue with M$ is that fact that they are based in the USA, and USA laws/regulations consider encryption to be a munition! (like a bomb!) and has ridiculous export restrictions on cryptography. As a result, many XP systems only support 40 or 56 bit mppe. As your kernel is probably compiled for 128 bit?...you immediately see a possible problem.

Personally, I cot so fed up with this problem that I've now switched to using Open VPN. It is much easier to configure and set up. The GUI for Windows is intuitive and provided the same degree of functionality as the PPTP setup. Only negative (or you could consider it as a positive?) is that all the code is user side (not compiled into the kernel), which potentially means that performance is slightly lower, but potentially more secure, potentially less likely to go wrong.

Hopefully my initial thoughts might trigger a thought that you need to alter something, alternatively, go here and try this:

http://openvpn.net/

..and you want to use version 2.0 - forget the 1.x version

HTH:)

pjedmond

Try adding:

mppe-40

after mppe-128 (assuming that you've compiled those modules) in your options file. That way, the lower strngth cryptography should be useable.

pjedmond

require-chap
require-mppe-128
require-mschap-v2
require-mppe-stateless

stipulates the only method of connection that will be accepted.....so you probably need to remove the require-mppe-128 line in order to allow mppe-40.

Obviously, you need to be *really* careful with what is altered here, as I don't want to end up with a default 'no encryption' connection or something equally bad!

Anyway, hopefully the above has given you some pointers:)

ASKER CERTIFIED SOLUTION

pjedmond

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Murdoc

ASKER

Hi pjedmond

I found out that pppd wasn't patched properly :((

Really thanks for help . Now everything works well :).

You was the only person trying to help me so points are going to you

regards

pjedmond

Glad to see that you've got it sorted. As you can see from the number of thoughts that I threw at you, there is loads that can go wrong! In most cases where I used to deal with this, I normally ended up cleaning out everything, and restarting from scratch. If it helps you feel better, I consider that the pppd in this context is probably the most complex common daemon to get up and running:)