News: This forum is now permanently frozen.
Pages: [1]
Topic: PPTP VPN , Linux RoadWarrior Client  (Read 3563 times)
« on: May 10, 2007, 16:12:45 »
jarmstrong *
Posts: 3

Hi,

I am having issue trying to get a PPTP linux client up and running against my monowall 1.23 system and I am seeing the messages listed below on the monowall side. On the Linux client side I am just seeing "CCP terminated". It looks like m0n0wall is not negotiating the proper encryption level but I am not positive what to do to get this link up.

Does anyone have any pointers that might help me with this?


========== Sys Log Exerpts from m0n0wall ===========================

May 10 08:44:40 mpd: [pt0] CCP: state change Closing --> Closed
May 10 08:44:40 mpd: [pt0] CCP: Close event
May 10 08:44:40 mpd: [pt0] CCP: failed to negotiate required encryption
May 10 08:44:40 mpd: [pt0] CCP: encryption required, but MPPE was not negotiated in both directions
May 10 08:44:40 mpd: [pt0] CCP: LayerDown
May 10 08:44:40 mpd: [pt0] CCP: SendTerminateReq #55
May 10 08:44:40 mpd: [pt0] CCP: state change Opened --> Closing
May 10 08:44:40 mpd: [pt0] CCP: Close event
May 10 08:44:40 mpd: [pt0] CCP: parameter negotiation failed
May 10 08:44:40 mpd: [pt0] CCP: No compression negotiated
May 10 08:44:40 mpd: [pt0] CCP: LayerUp
May 10 08:44:40 mpd: [pt0] CCP: state change Ack-Sent --> Opened


May 10 08:44:40 mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid

May 10 08:44:40 mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid
May 10 08:44:40 mpd: [pt0] IPCP: rec'd Configure Request #2 link 0 (Ack-Rcvd)
May 10 08:44:40 mpd: [pt0] CCP: SendConfigReq #54
May 10 08:44:40 mpd: MPPC
May 10 08:44:40 mpd: [pt0] CCP: rec'd Configure Reject #53 link 0 (Ack-Sent)
May 10 08:44:40 mpd: [pt0] CCP: state change Req-Sent --> Ack-Sent
May 10 08:44:40 mpd: [pt0] CCP: SendConfigAck #1
May 10 08:44:40 mpd: [pt0] CCP: rec'd Configure Request #1 link 0 (Req-Sent)
May 10 08:44:40 mpd: [pt0] IPCP: state change Req-Sent --> Ack-Rcvd
May 10 08:44:40 mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid


May 10 08:44:40 mpd: COMPPROTO VJCOMP, 16 comp. channels, allow comp-cid
May 10 08:44:40 mpd: [pt0] IPCP: rec'd Configure Request #1 link 0 (Req-Sent)
May 10 08:44:40 mpd: 0x010000e0: MPPE, 40 bit, 56 bit, 128 bit, stateless
May 10 08:44:40 mpd: MPPC
May 10 08:44:40 mpd: [pt0] CCP: Checking whether 128 bits are enabled -> yes
May 10 08:44:40 mpd: [pt0] CCP: Checking whether 56 bits are enabled -> yes
May 10 08:44:40 mpd: [pt0] CCP: Checking whether 40 bits are enabled -> yes
« Reply #1 on: May 11, 2007, 03:48:32 »
cmb *****
Posts: 851

Seems to be a common problem Linux PPTP clients have trying to connect to MPD. The Windows PPTP client will work with a default configuration, you might want to verify that you can connect properly with the Windows PPTP client. If so, you'll probably find better assistance in a group more familiar with Linux PPTP clients, as I don't think you'll find a lot of that expertise here.
« Reply #2 on: May 18, 2007, 15:22:07 »
jarmstrong *
Posts: 3

Using KVPNC

Ok, I got this working here are the settings I used:

Refuse 40 bit
Require MPPE
Get DNS From Peer
Refuse EAP
Do not use BSD Comp.
Use no IP by default
Do not use MPPC
"Keep Default Route"

Under NAT> Add remote network, but with no gateway 192.168.0.0/24

Uder General> Do not Ping, Do not use status check, do not reconnect when lost
« Reply #3 on: June 03, 2007, 01:02:35 »
bretticus *
Posts: 2

I use Ubuntu and consequently pptp-linux (I really like the network applet plugin.) I have no problems connecting from my linux computer. I suggest you try the Windows connect. One issue I discovered when I initially setup my home vpn, is that I needed to configure our firewall (pix) at work for the protocol. I don't remember the details and someone here can hopefully make up for it if they read this (you know...you struggle with something, do it successfully, then NEVER do it again. Then you completely forget Smiley It seems like PPTP either needs an unsolicited connection from the remote end (which seems strange actually) or Cisco decided to do a fixup for the protocol on the Pix because something is inherently insecure about the protocol (which also seems strange.) Anyway the point is, if you can't get it working on Windows, you might consider making some firewall changes at the client side.   
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines