PPP problems: Could not determine local IP address (GOOD address rejected from ipcp?)
Xavier ROCHE
(protocol MS-CHAP-V2). I read many other "Could not determine local IP
address" problems and FAQ, and:
- I correctly specified localip/remoteip
localip 192.168.0.234-238
remoteip 192.168.0.234-238
- I don't use 'noipdefault'
- The pppd seems to give correct IP address, but the client seems to
reject it ?!
Here are some log events:
ChapReceiveResponse: rcvd type MS-CHAP-V2
sent [CHAP Success id=0x1 "..."]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Timeout 0x80501a4:0x80778e0 in 3 seconds.
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Timeout 0x80501a4:0x8077a20 in 3 seconds.
MSCHAP-v2 peer authentication succeeded for main\\test
Okay, logged in, fine. Problems occurs with a "returning Configure-NAK"
:
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.234>
<ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
ipcp: returning Configure-NAK
sent [IPCP ConfNak id=0x1 <addr 192.168.0.235> <ms-dns1 192.168.0.1>
<ms-wins 192.168.0.1> <ms-dns3 192.168.0.1> <ms-wins 192.168.0.1>]
rcvd [IPCP ConfAck id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03
2f]
Untimeout 0x80501a4:0x8077a20.
rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
<ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
<ms-wins 192.168.0.1>]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
<ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
<ms-wins 192.168.0.1>]
Untimeout 0x80501a4:0x80778e0.
ipcp: up
Could not determine local IP address
ipcp: down
sent [IPCP TermReq id=0x2 "Could not determine local IP address"]
Timeout 0x80501a4:0x80778e0 in 3 seconds.
I spent many time to check and check again, modifying options, disabling
ms-dns/ms-wins and nothing is working well.. My current options:
name foobar
auth
require-chap
####noipdefault
+chap
+chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless
ms-dns 192.168.0.1
ms-wins 192.168.0.1
lock
debug 99
kdebug 99
logfile /etc/ppp/pptpd-pppd.log
By the way, this is a ppp connection through pptp link - might be the
reason?
Clifford Kite
> Okay, logged in, fine. Problems occurs with a "returning Configure-NAK":
> rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.234>
> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
> ipcp: returning Configure-NAK
> sent [IPCP ConfNak id=0x1 <addr 192.168.0.235> <ms-dns1 192.168.0.1>
> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1> <ms-wins 192.168.0.1>]
The Nak isn't the problem. The IP address 192.168.0.235 that pppd
suggests that the remote use above is accepted by the peer. That IP
address doesn't appear in any of the configuration stuff in your post.
> rcvd [IPCP ConfAck id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
This is likely the problem. The peer Acks the earlier IPCP request for
0.0.0.0 and pppd wants a real IP address. Something happened to cause
pppd to request 0.0.0.0, which is the way to ask the peer to supply your
IP address. You didn't use a pppd option of the form ":192.168.0.235"
when you should have used "192.168.0.235:", did you?
> rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
> <ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
> <ms-wins 192.168.0.1>]
> ipcp: returning Configure-ACK
> sent [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
> <ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
> <ms-wins 192.168.0.1>]
Here the 192.168.0.235 is accepted as the remote IP address.
...
> By the way, this is a ppp connection through pptp link - might be the
> reason?
Maybe, but this isn't a Linux standard track pppd. I'm not familiar
with the options format you show being used, or with PPTP problems.
For example, the option specifications (if that's what they are)
localip 192.168.0.234-238
remoteip 192.168.0.234-238
are not standard track pppd options.
--
Clifford Kite <kite@inet% port.com> Not a guru. (tm)
/* Editing with vi is a lot better than using a huge swiss army knife.
Use =} to wrap paragraphs in vi. Or put map ^] !}fmt -72^M in
~/.exrc and use ^] to wrap to 72 columns or whatever you choose. */
Bill Unruh
]I have problems with W98 machine that can't connect to a linux pppd box
](protocol MS-CHAP-V2). I read many other "Could not determine local IP
]address" problems and FAQ, and:
]- I correctly specified localip/remoteip
] localip 192.168.0.234-238
] remoteip 192.168.0.234-238
]- I don't use 'noipdefault'
]- The pppd seems to give correct IP address, but the client seems to
]reject it ?!
No, it does not! You confNak which is "I reject your parameters
(0.0.0.0) and make a suggestion of something I would accept if you were
to ask". They ask and you accept. But you never tell them what your
address is. Put in a line like
192.168.1.1:
into your ppp/options file.
(That is your address).
]Here are some log events:
]ChapReceiveResponse: rcvd type MS-CHAP-V2
]sent [CHAP Success id=0x1 "..."]
]sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
]Timeout 0x80501a4:0x80778e0 in 3 seconds.
]sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
]Timeout 0x80501a4:0x8077a20 in 3 seconds.
]MSCHAP-v2 peer authentication succeeded for main\\test
]Okay, logged in, fine. Problems occurs with a "returning Configure-NAK"
]:
]rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.234>
]<ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
They ask for the addrewss 192.168.0.234
]ipcp: returning Configure-NAK
]sent [IPCP ConfNak id=0x1 <addr 192.168.0.235> <ms-dns1 192.168.0.1>
]<ms-wins 192.168.0.1> <ms-dns3 192.168.0.1> <ms-wins 192.168.0.1>]
You say no and suggest 235 instead for them. Why I do not know. There
must be something which you have not told us about how you call pppd or
the options.
]rcvd [IPCP ConfAck id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
You seem to have real problems. You sent them an address of 0.0.0.0 and
they totally stupidly accepted this. This is completely and utterly
brain damaged behaviour.
You have to decide-- is it he linux machine or the remote machine that
is going to decide on the addresses. As it is you seem to have it set up
so that the Linux box tells the other side what address it should use,
but does not know its own address., which is stupid.
]rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03
]2f]
]Untimeout 0x80501a4:0x8077a20.
]rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
]<ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
]<ms-wins 192.168.0.1>]
They comply with your suggestions,
]ipcp: returning Configure-ACK
]sent [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 192.168.0.235>
]<ms-dns1 192.168.0.1> <ms-wins 192.168.0.1> <ms-dns3 192.168.0.1>
]<ms-wins 192.168.0.1>]
And you, as you promised, accept them.
]Untimeout 0x80501a4:0x80778e0.
]ipcp: up
]Could not determine local IP address
Right. You suggested 0.0.0.0 which is a request for the far side to
please suggest something sensible, and they then accepted that!!
]ipcp: down
]sent [IPCP TermReq id=0x2 "Could not determine local IP address"]
]Timeout 0x80501a4:0x80778e0 in 3 seconds.
]I spent many time to check and check again, modifying options, disabling
]ms-dns/ms-wins and nothing is working well.. My current options:
]name foobar
]auth
]require-chap
]####noipdefault
]+chap
]+chapms
]+chapms-v2
Uh, the above 5 lines all say similar things. require-chap is compeltey
equivalent to +chap. Also these all mean tht you want the far side to
authenticate themselves to you. Why? Especially why do you DEMAND
chapms-v2. It should be shot and burried, not encouraged.
]mppe-40
]mppe-128
]mppe-stateless
]ms-dns 192.168.0.1
]ms-wins 192.168.0.1
]lock
]debug 99
]kdebug 99
Get rid of kdebug. Also please when you post, post the exact debug
output. You have edited yours, and since you admit you do not know what
is wrong, you also do not know what the crucial parts of the debug
output are.
]logfile /etc/ppp/pptpd-pppd.log
James Carlson
> I have problems with W98 machine that can't connect to a linux pppd box
> (protocol MS-CHAP-V2). I read many other "Could not determine local IP
> address" problems and FAQ, and:
Win98 won't assign an IP address to its peer. So, when you send
0.0.0.0 as your IP address, Win98 happily (and bogusly) acks that
without giving a new address for your side. You should not send your
address as 0.0.0.0 to a Win98 host because of this known bug.
> I spent many time to check and check again, modifying options, disabling
> ms-dns/ms-wins and nothing is working well.. My current options:
I see no IP addresses in your options.
> name foobar
> auth
> require-chap
> ####noipdefault
This is the option that causes pppd to send 0.0.0.0 to the peer as its
IP address. What's on pppd's command line? Are there any other
configuration files? This option is being added somewhere. That's
what's causing the problem.
> debug 99
That doesn't make sense. "debug" is a stand-alone option. It doesn't
take an argument.
> kdebug 99
Don't use that unless you're having kernel problems. It will just
confuse things. At the moment, this looks like a negotiation problem,
not a kernel problem.
(Also, "99" is an invalid number for kdebug. Valid values are 0 to 7;
it's a bit field.)
> logfile /etc/ppp/pptpd-pppd.log
*PLEASE* post complete debug logs. Excerpts are often not helpful.
> By the way, this is a ppp connection through pptp link - might be the
> reason?
Maybe. Does the PPTP daemon invoke pppd? If so, does it add its own
options?
--
James Carlson <car...@workingcode.com>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp
Xavier ROCHE
Thanks to Clifford Kite, Bill Unruh and James Carlson for their help -
unfortunately this is still not working! :((((
In fact, I'm trying to do something slightly complex.
The server is connected to the Internet through ppp0:
+------------+ +-----------+
| | --PPP-----------------> | Internet |
| Server | --PPTP---------PPTPD-> | |
+------------+ +-----------+
And the remote client connects to this server using its internet
connection, with VPN tunneling:
+------------+ +-----------------+
| | <-PPP------------------ | W9x/Lnx Client |
| Server | <-PPTPD----------PPTP- | |
+------------+ +-----------------+
The server then has ppp0 for its own connection, and open ppp1 for the
client. PPTP client is used for ppp0 (to connect the server to the
internet) and PPTPD is used to accept client connection
I allowed for pptp 192.168.0.234-238 as IP addresses and specified the
option file in /etc/pptpd-options
This file (/etc/pptpd-options) is read, as syntax errors in it gives me
error messages in the logs!
/etc/pptpd.conf: (complete file)
localip 192.168.0.234-238
remoteip 192.168.0.238-242
option /etc/ppp/pptpd-options
debug
The pppd options file is standard, I just added some m$-like
authentication (I know, they are bad, but I can't do better for now)
/etc/pptpd-options: (complete file)
192.168.0.238:
auth
+chap
+chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless
debug
kdebug 7
logfile /etc/ppp/pppd.log
Okay. 192.168.0.238 should be the address given by pppd.
I relaunch pptpd regularly (killall pptpd; pptpd) and double check if
the lognames are okay
First tested with W98 client
Here are the /etc/ppp/pppd.log log (complete file)
$ tail -f /etc/ppp/pppd.log -n 0
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap 81> <magic
0x2f7cbe22> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <magic 0x2ba442> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <magic 0x2ba442> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap 81> <magic
0x2f7cbe22> <pcomp> <accomp>]
sent [CHAP Challenge id=0x1 <e8a2cecd618b541e0ff6e9d4de87fbe9>, name =
"hidden"]
rcvd [CHAP Response id=0x1 <hidden>, name = "main\\test"]
sent [CHAP Success id=0x1 "S=E41DFC829EA8F0DB62220DC2138CA1F2FEFCDDDF"]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
MSCHAP-v2 peer authentication succeeded for main\\test
rcvd [IPCP ConfReq id=0x1 <addr 192.168.0.234> <ms-dns1 0.0.0.0>
<ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3
0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 31> <lzs 0 1 4>]
sent [CCP ConfRej id=0x1 <mppe 1 0 0 60> <lzs 0 1 4>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfReq id=0x2]
rcvd [IPCP ConfReq id=0x2 <addr 192.168.0.234>]
sent [IPCP ConfNak id=0x2 <addr 192.168.0.238>]
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
rcvd [IPCP ConfAck id=0x2 <addr 0.0.0.0>]
rcvd [CCP ConfAck id=0x2]
rcvd [IPCP ConfReq id=0x3 <addr 192.168.0.238>]
sent [IPCP ConfAck id=0x3 <addr 192.168.0.238>]
Could not determine local IP address
sent [IPCP TermReq id=0x3 "Could not determine local IP address"]
rcvd [CCP TermReq id=0x3]
CCP terminated by peer
sent [CCP TermAck id=0x3]
Compression disabled by peer.
rcvd [IPCP TermAck id=0x3]
sent [LCP TermReq id=0x2 "No network protocols running"]
rcvd [LCP TermReq id=0x2]
sent [LCP TermAck id=0x2]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Connect time 0.1 minutes.
Sent 506 bytes, received 463 bytes.
With W2000, same problem..
tail -f /etc/ppp/pppd.log -n 0
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap 81> <magic
0xb1c33bdd> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap 81> <magic
0xb1c33bdd> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <magic 0x5e356685> <pcomp> <accomp> < 0d 03 06>
< 11 04 06 4e> < 13 09 03 00 50 ba c5 f2 a2>]
sent [LCP ConfRej id=0x1 < 0d 03 06> < 11 04 06 4e> < 13 09 03 00 50 ba
c5 f2 a2>]
rcvd [LCP ConfReq id=0x2 <magic 0x5e356685> <pcomp> <accomp>]
sent [LCP ConfAck id=0x2 <magic 0x5e356685> <pcomp> <accomp>]
sent [CHAP Challenge id=0x1 <6d330a1a0c251a55b12c5cc445323dd1>, name =
"hidden"]
rcvd [LCP code=0xc id=0x3 5e 35 66 85 4d 53 52 41 53 56 35 2e 30 30]
sent [LCP CodeRej id=0x2 0c 03 00 12 5e 35 66 85 4d 53 52 41 53 56 35 2e
30 30]
rcvd [LCP code=0xc id=0x4 5e 35 66 85 4d 53 52 41 53 2d 31 2d 59 50 44
45 56]
sent [LCP CodeRej id=0x3 0c 04 00 15 5e 35 66 85 4d 53 52 41 53 2d 31 2d
59 50 44 45 56]
rcvd [CHAP Response id=0x1
<9c4efe473e4e5e875000000000000000099550e7a7ca1915cf7ec25727943e5e47e854ee223ddc00>,
na
me = "test"]
sent [CHAP Success id=0x1 "S=7D13AD3DA04A8B951992C8C59910BD84EBB3EF40"]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
MSCHAP-v2 peer authentication succeeded for test
rcvd [IPXCP ConfReq id=0x5 <network 0> <node 02ee2752d0dc>]
Unsupported protocol 'Novell IPX Control Protocol' (0x802b) received
sent [LCP ProtRej id=0x4 80 2b 01 05 00 12 01 06 00 00 00 00 02 08 02 ee
27 52 d0 dc]
rcvd [IPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins
0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x7 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3
0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 192.168.0.238>]
rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfReq id=0x2]
rcvd [IPCP ConfReq id=0x8 <addr 0.0.0.0>]
sent [IPCP ConfNak id=0x8 <addr 192.168.0.238>]
rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 192.168.0.238>]
sent [IPCP ConfReq id=0x3]
rcvd [CCP ConfNak id=0x2 <mppe 0 0 0 0>]
sent [CCP ConfReq id=0x3]
rcvd [IPCP ConfReq id=0x9 <addr 192.168.0.238>]
sent [IPCP ConfAck id=0x9 <addr 192.168.0.238>]
rcvd [IPCP ConfAck id=0x3]
Could not determine local IP address
sent [IPCP TermReq id=0x4 "Could not determine local IP address"]
rcvd [CCP ConfNak id=0x3 <mppe 0 0 0 0>]
sent [CCP ConfReq id=0x4]
sent [IPCP TermReq id=0x5 "Could not determine local IP address"]
sent [CCP ConfReq id=0x4]
sent [LCP TermReq id=0x5 "No network protocols running"]
rcvd [IPCP TermAck id=0x4 "Could not determine local IP address"]
rcvd [CCP ConfNak id=0x4 <mppe 0 0 0 0>]
rcvd [IPCP TermAck id=0x5 "Could not determine local IP address"]
rcvd [CCP ConfNak id=0x4 <mppe 0 0 0 0>]
rcvd [LCP TermAck id=0x5 "No network protocols running"]
Connection terminated.
Connect time 0.2 minutes.
Sent 739 bytes, received 1690 bytes.
I tried to remove 192.168.0.238:, or use :192.168.0.238 and even
192.168.0.239:192.168.0.238, same effect
I also tried noauth (stupid), same effect, don't work
I tried also noipdefault (stupid too) - don't work
Then I tried to disable all m$-like auth, wih no security, and the
"Could not determine local IP address" is still here
I also tried to disable localip / remoteip in pptp, same effect
I really wonder if the pptp layer is responsible or not for these
problems - darn!
James Carlson
[...]
> sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
As I said before, the only thing that makes a stock pppd issue its own
address as 0.0.0.0 is the "noipdefault" option. Something you're
doing must be enabling that option. Perhaps it's hard-coded into the
PPTP implementation you're using or it's built into the (obviously
nonstandard) version of pppd you're using.
You need to get rid of that option or the link just isn't going to
work. You should probably take this up with the maintainer of the
PPTP implementation.
--
James Carlson, Internet Engineering <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp
Xavier ROCHE
Yes, that's what I supposed too.. but the pppd launched by pptp is :
root 3051 3048 0 14:24 ? 00:00:00 /usr/sbin/pppd local
file /etc/ppp/pptpd-options 115200 192.168.0.254:192.168.0.239
No "noipdefault" options here :(
The /etc/ppp/pptpd-options is still:
auth
require-chap
+chap
+chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless
ms-dns 192.168.0.1
ms-wins 192.168.0.1
debug
kdebug 7
logfile /etc/ppp/pppd.log
But pppd still send
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
This is really crazy. Maybe due to the MS-patch for pppd.. I'm still
investigating
Thanks for your help, the problem is at least detected (the 0.0.0.0)
Xavier ROCHE
and it's still not working (I disabled all ms-auth, of course)
I really don't understand why the pppd still send this stupid ConfReq
id=0x2 <addr 0.0.0.0> ... no "noipdefault" and correct local/remote ip
given
James Carlson
> Unfortunately, this is not the pppd fault, I tried with the standard one
> and it's still not working (I disabled all ms-auth, of course)
> I really don't understand why the pppd still send this stupid ConfReq
> id=0x2 <addr 0.0.0.0> ... no "noipdefault" and correct local/remote ip
> given
If your local host name can't be resolved to an IP address and you're
not supplying a local address, then I suppose that it's possible to
end up with 0.0.0.0 here without using "noipdefault."
Since I think both of those preconditions are false here, I must still
assert that you've got to be somehow specifying "noipdefault" or
otherwise setting disable_defaultip in pppd/ipcp.c. Look everywhere.
Are you using plugins? These could set that variable for you. Have
you checked all possible configuration files? /etc/ppp/options,
/etc/ppp/options.ttyname (probably not used for tunneled connections),
$HOME/.ppprc, command line, plus any files read by the "call" or
"file" option included in any of those other locations. Are you sure
that pppd is 'clean'? You're obviously using a modified version (the
stock version doesn't do MPPE); is "disable_defaultip" anywhere in the
patch?
Xavier ROCHE
I found what's going on!
I have an /etc/ppp/options file with noipdefault. BUT as I was using
/etc/ppp/pptpd-options, I didn't realized that the pptpd just pass to
the pppd the commandline:
/usr/sbin/pppd file /etc/ppp/pptpd-options
AND THIS is totally WRONG, because 'file' is just an include - the
/etc/ppp/options is still included, TOO!
I'll have to change this, because the default options file is really
wrong
Bill Unruh
>Thanks to Clifford Kite, Bill Unruh and James Carlson for their help -
>unfortunately this is still not working! :((((
>In fact, I'm trying to do something slightly complex.
>The server is connected to the Internet through ppp0:
>+------------+ +-----------+
>| | --PPP-----------------> | Internet |
>| Server | --PPTP---------PPTPD-> | |
>+------------+ +-----------+
Why? What do you get for tunneling ppp through a ppp link?
>And the remote client connects to this server using its internet
>connection, with VPN tunneling:
>+------------+ +-----------------+
>| | <-PPP------------------ | W9x/Lnx Client |
>| Server | <-PPTPD----------PPTP- | |
>+------------+ +-----------------+
>The server then has ppp0 for its own connection, and open ppp1 for the
>client. PPTP client is used for ppp0 (to connect the server to the
>internet) and PPTPD is used to accept client connection
>The pppd options file is standard, I just added some m$-like
>authentication (I know, they are bad, but I can't do better for now)
>/etc/pptpd-options: (complete file)
>192.168.0.238:
>auth
>+chap
>+chapms
>+chapms-v2
I am not sure you want all three. Just chapms-v2 should do shouldn't it?
>mppe-40
>mppe-128
>mppe-stateless
Again, are you sure you want all three?
>debug
>kdebug 7
No please don;t. kdebug tends to just clutter up the file without giving
much useful info.
>logfile /etc/ppp/pppd.log
>Okay. 192.168.0.238 should be the address given by pppd.
It should be the local address insited on by pppd.
>First tested with W98 client
>Here are the /etc/ppp/pppd.log log (complete file)
>$ tail -f /etc/ppp/pppd.log -n 0
>Using interface ppp1
>Connect: ppp1 <--> /dev/pts/1
>sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap 81> <magic
>0x2f7cbe22> <pcomp> <accomp>]
OK, you start off by asking for chap 81. Do you really want to do this?
Why not try chap 05 first and see if they will accept that
>rcvd [LCP ConfReq id=0x1 <magic 0x2ba442> <pcomp> <accomp>]
>sent [LCP ConfAck id=0x1 <magic 0x2ba442> <pcomp> <accomp>]
>rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap 81> <magic
>0x2f7cbe22> <pcomp> <accomp>]
>sent [CHAP Challenge id=0x1 <e8a2cecd618b541e0ff6e9d4de87fbe9>, name =
>"hidden"]
>rcvd [CHAP Response id=0x1 <hidden>, name = "main\\test"]
>sent [CHAP Success id=0x1 "S=E41DFC829EA8F0DB62220DC2138CA1F2FEFCDDDF"]
>sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
No. Something is wrong here. Your pppd should not be sending 0.0.0.0 as
the address request. You must have put
noipdefault
or
0.0.0.0:
somewhere (on the pppd command line perhaps?) Or do you have a pppd
which has be munged by someone?
>sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
>MSCHAP-v2 peer authentication succeeded for main\\test
>rcvd [IPCP ConfReq id=0x1 <addr 192.168.0.234> <ms-dns1 0.0.0.0>
><ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
The want address 234 and want youto supply dns and wins addresses.
>sent [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3
>0.0.0.0> <ms-wins 0.0.0.0>]
You refuse the wins and dns. They should come back with just the address
request.
>rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 31> <lzs 0 1 4>]
>sent [CCP ConfRej id=0x1 <mppe 1 0 0 60> <lzs 0 1 4>]
>rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
>sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
Again somthing has gone wrong somewhere.
>rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
>sent [CCP ConfReq id=0x2]
>rcvd [IPCP ConfReq id=0x2 <addr 192.168.0.234>]
>sent [IPCP ConfNak id=0x2 <addr 192.168.0.238>]
Now you try to tell them you would rather have 238. Something is very
wrong. You must be using a different options file than the one you told
us about, or have some weird stuff on the command line. What we are
seeing in this debug log is at total variance with what you say is in
your options file.
>rcvd [CCP ConfReq id=0x2]
>sent [CCP ConfAck id=0x2]
>rcvd [IPCP ConfAck id=0x2 <addr 0.0.0.0>]
And the far side is dumb. But then you do not know what your own address
is, so why should they know?
>rcvd [CCP ConfAck id=0x2]
>rcvd [IPCP ConfReq id=0x3 <addr 192.168.0.238>]
>sent [IPCP ConfAck id=0x3 <addr 192.168.0.238>]
>Could not determine local IP address
>sent [IPCP TermReq id=0x3 "Could not determine local IP address"]
>rcvd [CCP TermReq id=0x3]
>CCP terminated by peer
>sent [CCP TermAck id=0x3]
>With W2000, same problem..
This is not a problem with the far side, this is a problem with your
side. Something is very broken on the linux side. These reports and your
claims do not agree with each other at all.
Xavier ROCHE
It seems that pptpd always include /etc/ppp/options, even with the
'option' specified. This is annoying when using multiple ppp and even
connecting through ppp
Fix:
I have erased (created an empty file, in fact) /etc/ppp/options and
created different /etc/ppp/options.ttya0, and so.. and it's now working
well
Xavier ROCHE
> Why? What do you get for tunneling ppp through a ppp link?
The internet connection itself through adsl
> I am not sure you want all three. Just chapms-v2 should do shouldn't it?
But the two other might be alternatives if chapms-v2 is not supported?
> the address request. You must have put
> noipdefault
Right - see my "fix" message - this was (partially) due to pptpd
> OK, you start off by asking for chap 81. Do you really want to do this?
> Why not try chap 05 first and see if they will accept that
Well, how do you do that? Can't find it on ppp faq..
Bill Unruh
>> OK, you start off by asking for chap 81. Do you really want to do this?
>> Why not try chap 05 first and see if they will accept that
>Well, how do you do that? Can't find it on ppp faq..
Remove the +chap81. Does this really reject anyone? As far as I know
all MS systems accept chap05 as an authentication protocol if asked
to do so. Chap 81 was an attempt by MS to put their total botchup of
chap80 behind them with not much in the way of advantage. It should
not be encouraged.
The ppp faq does not mention chap 81 at all. There is no official
patch for pppd for chap81. There is just a black patch which also
supports the proprietary ( meaning you should really be paying
royalty fees for using it) compression/encryption which usually goes
with chap81. In fact both the two MS algorithm +chap-ms and +chap-81
are additions to pppd which are not official AFAIK, so how they were
kludged in would not be a part of any faq.
The official term is just "require-chap" (+chap as a synonym is an
undocumented feature which may well disappear in future versions)
Xavier ROCHE
Bill Unruh wrote:
> Remove the +chap81. Does this really reject anyone? As far as I know
Is this identical to "chapms" ?
> There is just a black patch which also
> supports the proprietary ( meaning you should really be paying
> royalty fees for using it) compression/encryption which usually goes
Yes, and the patch is really dirty, the encryption is not supported
unless you patch the kernel :(
I really wonder why the "standard" pppd doesn't support highest
encryption standards ; not for chap, but encrypting ppp packets itself.
Sending the password in cypher mode is better, encrypting the flow
(would be) is much better
James Carlson
> I really wonder why the "standard" pppd doesn't support highest
> encryption standards ; not for chap, but encrypting ppp packets itself.
Several reasons:
- Encryption is (sadly) export-controlled and causes all sorts
of legal hassles.
- Encryption is much better done in IPSec and user level
applications (such as ssh and PGP). Encrypting the link
layer usually just gives a false sense of security, which is
worse than no security at all.
- Encryption at the link layer using standard protocols is not
a common PPP feature, so the chance of interoperability is
somewhat low.
If I were prioritizing PPP features, I'd rather see robust plugins for
(say) RADIUS and DIAMETER than extensive encryption support. (That's
not to say encryption might not be done first.)
> Sending the password in cypher mode is better, encrypting the flow
> (would be) is much better
If you're using standard PPP compression, your password is not
encrypted. Encryption doesn't start until after authentication is
complete. (It's rather hard to pick encryption keys otherwise.)
Bill Unruh
]Bill Unruh wrote:
]> Remove the +chap81. Does this really reject anyone? As far as I know
]Is this identical to "chapms" ?
No. Microsoft keeps inventing new "standards." They mess up ( as they
did for chap ms= chap80) and then redefine the "standard" to change it
to something which is marginally better than their old chap80 ( but
still no better than the original true standard chap05). They then
invent still another "standard" chap81, with the excuse that they want
to support encryption. But the encryption they support is proprietary
and not a great job at that.
.
]> There is just a black patch which also
]> supports the proprietary ( meaning you should really be paying
]> royalty fees for using it) compression/encryption which usually goes
]Yes, and the patch is really dirty, the encryption is not supported
]unless you patch the kernel :(
]I really wonder why the "standard" pppd doesn't support highest
]encryption standards ; not for chap, but encrypting ppp packets itself.
]Sending the password in cypher mode is better, encrypting the flow
](would be) is much better
Because what MS produced is proprietary. Ie, they would sue the writers
of pppd if they did include it, and sue any distributor who distributed
it.
Note that with Carlson' Request for Comments on a new stardard
supporting SRP on ppp chap the way is finally open for a real standard
which is much better than anything out there now, and a way of
supporting really good crypto. The present request with just DES or 3DES
could probably be improved on (DES is slow and 3DEs even slower --
adding in something like RC4 or blowfish or AES(Rijndahl) would be
better, but that is a minor modification.) but it already vastly exceeds
anything out there.
Remember that ppp is usually used over phone lines with modems.
Apparently because of the echo cancellation properties of high speed
modems it is very hard to tap them and to get out anything sensible. Ie,
in the usual way of using ppp, the encryption is not such a big deal.
However, with all these pppoe, pppoatm, pppoppp,.... that seem to be
sprouting up like dandilions, it is a bigger issue. As I say, Carlson's
recent contribution is a real step in the right direction here.
Xavier ROCHE
> Note that with Carlson' Request for Comments on a new stardard
> adding in something like RC4 or blowfish or AES(Rijndahl) would be
This would be really great, especially with new encryption standards
> However, with all these pppoe, pppoatm, pppoppp,.... that seem to be
> sprouting up like dandilions, it is a bigger issue. As I say, Carlson's
> recent contribution is a real step in the right direction here.
May he be blessed for his RFC! :) Hope it'll became a standard soon..
You're right-the biggest problem is VPN through PPP - unsecure VPN lines
are really easy to tape, with built-in sniffing tools :(