Welcome to WebmasterWorld Guest from 34.228.30.69

Forum Moderators: bakedjake

Message Too Old, No Replies

PPTP client on FreeBSD - how to disable LCP

     
11:43 am on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


I want to connect a FreeBSD PPTP client to a server that doesn't support LCP but I can't find a way to disable LCP. This results in a 3 seconds connection (in the logs) and then bringing down the connection.

I have tried from a Windwows client and everything works fine, I had to disable LCP and require data encryption to get it to work.

According to the ppp docs it should not require almost anything to do the connection but that doens't seem to be the case, couldn't find a way to disable it manually too. I am running FreeBSD 5.2 with pptp-linux 1.3.1 and the guide at [freebsddiary.org...]
to configure the pptp link.

I also tried various combinations of the following options in ppp.conf:

# disable LCP # warning incorrect
# down lcp
# disable vjcomp
# disable MSCHAPv2
# disable mppe
# enable deflate pred1
# close lcp
# lcp-echo-interval 30
# lcp-echo-request 0
# open lcp
# set openmode passive
set openmode passive
set stopped 3
# disable lqr

I have this in the logs, it starts a disconnect after the lcp->open:

Mar 18 11:48:35 mtb ppp[2946]: tun0: Phase: deflink: lcp -> open
Mar 18 11:48:35 mtb ppp[2946]: tun0: Phase: bundle: Network
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: Signal 15, terminate.
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: Signal 15, terminate.
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: read (0): Got zero bytes
Mar 18 11:48:36 mtb ppp[2946]: tun0: LCP: deflink: LayerDown
Mar 18 11:48:36 mtb ppp[2946]: tun0: LCP: deflink: State change Opened --> Starting
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: open -> lcp
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: bundle: Terminate
Mar 18 11:48:36 mtb ppp[2946]: tun0: LCP: deflink: LayerFinish
Mar 18 11:48:36 mtb ppp[2946]: tun0: LCP: deflink: State change Starting --> Initial
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: Disconnected!
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: Connect time: 3 secs: 334 octets in, 873483 octets out
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: 9 packets in, 1426 packets out
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: total 291272 bytes/sec, peak 189 bytes/sec on Thu Mar 18 11:48:35 2004
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: deflink: lcp -> closed
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: bundle: Dead
Mar 18 11:48:36 mtb ppp[2946]: tun0: Phase: PPP Terminated (normal).

5:01 pm on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 28, 2003
posts:366
votes: 0


Interesting... You've gotten further than I've ever been able to get, while trying to connect to our Cisco PIX, with PPTP/IPSEC. I consistenly get a "network unreachable" error.

I'll give it another try, now that I just recently upgraded to 5.2.1.

I'll see if I encounter the same problem as you when I try again.

-MM

5:22 pm on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


I found a few similar questions on mailing lists/forums through Google, unfortunately none of the answered questions was the same problem as I have.
9:40 pm on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


Actually I got it working with the php-gtk config tool for pptp.
11:00 pm on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


Sorry for that misleading post. I actually tried it on Linux, and FreeBSD's ppp is a bit different. Will have to look for a way to convert the config.

PS. If you want I can post the ppp config that worked for me on Linux.

11:48 pm on Mar 18, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 28, 2003
posts:366
votes: 0


That'd be really cool if you could do that!

Much appreciated!

-MM

10:26 am on Mar 19, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


The config that php-pptp generated is:

/etc/ppp/chap-secrets
username peer-name password *

* is for IP addresses so you can probably change that. There's also a pap-secrets file with the same contents but if I am right (just guessing from the names) CHAP should be preferred to PAP.

And in /etc/ppp/peers/peer-name:

# name of tunnel, used to select lines in secrets files
remotename peer-name

# name of tunnel, used to name /var/run pid file
linkname peer-name

# name of tunnel, passed to ip-up scripts
ipparam peer-name

# data stream for pppd to use
pty "pptp vpn.ip.or.hostname --nolaunchpppd "

# domain and username, used to select lines in secrets files
name username

persist
#debug dump

# do not require the server to authenticate to our client
noauth

I don't have time to test now maybe sat/sun but I found some info suggesting that kernel ppp is closer to the linux one. I've only tried user ppp so far.

If you're trying on Linux you may have to tweak the routing table by hand, when I first got the connection working php-pptp messed up the routing and the Linux box was re-sending packets to the other end at around 1MB/s and using alsmost 100% cpu. Btw I'm using Debian 3.0, in its pptp docs it said that I need a patch for ppp to support pptp but it works fine.

Debian are making Debian GNU/KFreeBSD and they have ported their ppp to the FreeBSD kernel so as a last resort I can try that too ;-)

5:34 pm on Mar 25, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 12, 2003
posts:72
votes: 0


You're confused.

PPP and PPTP are two entirely different protocols. PPP runs over PPTP. LCP is PPP's Link Control Protocol, it's how pppd daemons communicate, and killing LCP neither has anything to do with PPTP nor does it make any sense to disable it.

Signal 15 is SIGTERM. I am not familiar with *BSD implementations of pppd and pptp so this is just a guess: pptp tunnel fails, pptp kills pppd with signal 15, no actual ppp (e.g. outer tunnel) connection happens.

Double check that you are connecting to the right VPN service, from the right address and that your router allow s GRE through.

6:35 pm on Mar 25, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


Nova I wished you were right but as I said above I am able to connect from a Linux box behind the FreeBSD so I know for sure it's not the network/filtering/wrong IPs.

If that would help I have the full log too and the following part repeats 4 times, that's why I though it's LCP not working. In windows you have to disable LCP extensions (now, I guess it uses a lite LCP or something):

Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Req-Sent
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa

Here's the full log with:
set log phase chat lcp ipcp ccp tun command

I would really appreciate it if you or someone else can help, I've posted on freebsd-questions too but I didn't get an answer there.

Mar 22 00:34:52 mtb ppp[9415]: Phase: Using interface: tun0
Mar 22 00:34:52 mtb ppp[9415]: Phase: deflink: Created in closed state
Mar 22 00:34:52 mtb ppp[9415]: tun0: Phase: PPP Started (direct mode).
Mar 22 00:34:52 mtb ppp[9415]: tun0: Phase: bundle: Establish
Mar 22 00:34:52 mtb ppp[9415]: tun0: Phase: deflink: closed -> opening
Mar 22 00:34:52 mtb ppp[9415]: tun0: Phase: deflink: Connected!
Mar 22 00:34:52 mtb ppp[9415]: tun0: Phase: deflink: opening -> carrier
Mar 22 00:34:53 mtb ppp[9415]: tun0: Phase: deflink: carrier -> lcp
Mar 22 00:34:53 mtb ppp[9415]: tun0: LCP: FSM: Using "deflink" as a transport
Mar 22 00:34:53 mtb ppp[9415]: tun0: LCP: deflink: State change Initial -->
Closed
Mar 22 00:34:53 mtb ppp[9415]: tun0: LCP: deflink: State change Closed -->
Stopped
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: deflink: LayerStart
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Stopped
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa
Mar 22 00:34:54 mtb ppp[9415]: tun0: LCP: deflink: State change Stopped -->
Req-Sent
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Req-Sent
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:34:57 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Req-Sent
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:35:00 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Req-Sent
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:35:03 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: deflink: SendConfigReq(1) state =
Req-Sent
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: ACFCOMP[2]
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: PROTOCOMP[2]
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: ACCMAP[6] 0x00000000
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: MRU[4] 1500
Mar 22 00:35:06 mtb ppp[9415]: tun0: LCP: MAGICNUM[6] 0xda445afa
Mar 22 00:35:09 mtb ppp[9415]: tun0: LCP: deflink: LayerFinish
Mar 22 00:35:09 mtb ppp[9415]: tun0: LCP: deflink: State change Req-Sent -->
Stopped
Mar 22 00:35:09 mtb ppp[9415]: tun0: LCP: deflink: State change Stopped -->
Closed
Mar 22 00:35:09 mtb ppp[9415]: tun0: LCP: deflink: State change Closed -->
Initial
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: deflink: Disconnected!
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: deflink: Connect time: 17 secs: 0
octets in, 260 octets out
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: deflink: 0 packets in, 5 packets
out
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: total 15 bytes/sec, peak 20
bytes/sec on Mon Mar 22 00:34:57 2004
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: deflink: lcp -> closed
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: bundle: Dead
Mar 22 00:35:09 mtb ppp[9415]: tun0: Phase: PPP Terminated (normal).

3:06 pm on Mar 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 12, 2003
posts:72
votes: 0


From what I see in your configuration, pppd invokes pptp (communicates with it via a pty) and then runs on top of it.

I dont know about pptp implementation on BSD*, but in Linux you can run it the other way around: pptp will connect the GRE tunnel, raise the VPN link, and -then- invoke pppd to negotiate with the remote. As I can't really decipher from your logs whether pptp connection is successful (and in case it's not, I can presume that pptp running under pppd will not behave the same way it does in Linux, which makes any my analysis of logs null and void), I can not be certain that the problem is on pppd side - I can't see any negotiation in pppd logs, just error messages.

Increase pppd log verbosity, rearrange so that pptp calls pppd and not the other way around and you might find out that the problem is entirely not where you think it is.

3:07 pm on Mar 29, 2004 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 12, 2003
posts:72
votes: 0


Oh! I totally forgot! What about the default route?
8:48 am on Apr 5, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


Unfortunately I couldn't find a way to do it in reverse on FreeBSD, the command pptp ip connection_name seems to do exactly the same as pppd -ddail connection_name (although in the latter one I don't understand where it is trying to connect ;-).

On Linux it's a bit strange, I have pppd call connection_name and it forks a pptp off it and I have another pptp process that's parent pid is 1.

PS. Thanks for reminding me about the routing, on Linux you have to have a host entry to the VPN ip or it won't work (actually it will work but keep resending packets at a pretty high rate the wrong route) and I didn't have one on FreeBSD. Unfortunately it didn't change anything.

8:26 am on Apr 6, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


I found an alternative way to configure pptp/ppp that looks pretty clonse to the Linux one, unfortunately that doesn't work too - same thing logged in ppp.log. I found that setup at [opennet.ru...] didn't quite understand the comments but the config is obvious ;-)

And also found one with kernel ppp: [bsdvault.net...]

didn't work for me neither.

Apr 6 00:59:11 mtb pppd[31594]: pppd 2.3.5 started by martin, uid 0
Apr 6 00:59:11 mtb pppd[31594]: Connect: ppp0 <--> /dev/ttyp6
Apr 6 00:59:13 mtb pptp[31595]: anon log[decaps_hdlc:pptp_gre.c:217]: PPP mode seems to be Asynchronous.
Apr 6 00:59:41 mtb pppd[31594]: LCP: timeout sending Config-Requests
Apr 6 00:59:41 mtb pppd[31594]: Connection terminated, connected for 1 minutes
Apr 6 00:59:42 mtb pptp[31595]: anon warn[decaps_hdlc:pptp_gre.c:209]: short read (0): Invalid argument
Apr 6 00:59:42 mtb pptp[31593]: anon log[callmgr_main:pptp_callmgr.c:236]: Closing connection
Apr 6 00:59:42 mtb pptp[31593]: anon log[pptp_conn_close:pptp_ctrl.c:357]: Closing PPTP connection
Apr 6 00:59:42 mtb pptp[31593]: anon log[pptp_write_some:pptp_ctrl.c:426]: write error: Broken pipe
Apr 6 00:59:42 mtb pptp[31593]: anon log[call_callback:pptp_callmgr.c:76]: Closing connection
Apr 6 00:59:44 mtb kernel: pid 31593 (pptp), uid 0: exited on signal 6 (core dumped)

10:05 am on Apr 8, 2004 (gmt 0)

Preferred Member

10+ Year Member

joined:Aug 3, 2002
posts:482
votes: 0


I finally got the VPN connection up using mpd from the ports collection. There's a howto in the FreeBSD handbook in the PPP over ATM section. The things is it's not always working and when I have the connection up I can't even ping the other side:

ping vpn
PING vpn (192.168.3.37): 56 data bytes
ping: sendto: Resource deadlock avoided
ping: sendto: Resource deadlock avoided
ping: sendto: No buffer space available

Routes are correctly added, I can see that from the debug output and with netstat -rn.

I found something similar at: [lists.freebsd.org...] and a link to a solution at: [cs.rpi.edu...] Can't check it because I can't establish the connection anymore :-(