News: This forum is now permanently frozen.
Pages: [1]
Topic: Trouble getting PPTP VPN configured.  (Read 20629 times)
« on: March 28, 2007, 20:19:04 »
jreineri *
Posts: 6

I am having trouble getting a PPTP VPN setup to work and would greatly appreciate any assistance in figuring out what I am doing wrong.

I have a m0n0wall setup with a private LAN network of 192.168.0.0/24.  My PPTP configuration has a server address of 192.168.102.250.   The remote address range is 192.168.102.64/28
 Not using RADIUS for authentication.

One user configured in PPTP users.  Name and password have been double checked.

One defined rule on the PPTP VPN rules tab:
Proto:* Source:PPTP Clients Port: *  Destination: * Port: *  Description: PPTP -> Any

Local net, NAT forwarding and other rules seem to be working perfectly.

My symptom is when I try to attach a PPTP session from any workstation I get:
MessageBox that says: "Connecting to 123.123.123.123"    IP address changed to protect the guilty.
after a few seconds that changes to:
MessageBox that says:  "Verifying Username and Password..."
after a much longer delay it changes to:
DialogBox that says:
Disconnected.  Error 619: yada - yada - yada

Thanks in advance for any assistance,
Jim

« Reply #1 on: March 29, 2007, 01:30:34 »
falcor *
Posts: 17

Going to need something from the PPTP server log to figure that one out.  Wink
« Reply #2 on: March 29, 2007, 04:50:33 »
jreineri *
Posts: 6

No problem, here is the log

Mar 28 10:26:37 router mpd: mpd: PPTP connection from 206.113.196.2:37087
Mar 28 10:26:37 router mpd: pptp0: attached to connection with 206.113.196.2:37087
Mar 28 10:26:37 router mpd: [pt0] IFACE: Open event
Mar 28 10:26:37 router mpd: [pt0] IPCP: Open event
Mar 28 10:26:37 router mpd: [pt0] IPCP: state change Initial --> Starting
Mar 28 10:26:37 router mpd: [pt0] IPCP: LayerStart
Mar 28 10:26:37 router mpd: [pt0] IPCP: Open event
Mar 28 10:26:37 router mpd: [pt0] bundle: OPEN event in state CLOSED
Mar 28 10:26:37 router mpd: [pt0] opening link "pt0"...
Mar 28 10:26:37 router mpd: [pt0] link: OPEN event
Mar 28 10:26:37 router mpd: [pt0] LCP: Open event
Mar 28 10:26:37 router mpd: [pt0] LCP: state change Initial --> Starting
Mar 28 10:26:37 router mpd: [pt0] LCP: LayerStart
Mar 28 10:26:37 router mpd: [pt0] device: OPEN event in state DOWN
Mar 28 10:26:37 router mpd: [pt0] attaching to peer's outgoing call
Mar 28 10:26:37 router mpd: [pt0] device is now in state OPENING
Mar 28 10:26:37 router mpd: [pt0] device: UP event in state OPENING
Mar 28 10:26:37 router mpd: [pt0] device is now in state UP
Mar 28 10:26:37 router mpd: [pt0] link: UP event
Mar 28 10:26:37 router mpd: [pt0] link: origination is remote
Mar 28 10:26:37 router mpd: [pt0] LCP: Up event
Mar 28 10:26:37 router mpd: [pt0] LCP: state change Starting --> Req-Sent
Mar 28 10:26:37 router mpd: [pt0] LCP: phase shift DEAD --> ESTABLISH
Mar 28 10:26:37 router mpd: [pt0] LCP: SendConfigReq #21
Mar 28 10:26:37 router mpd:  ACFCOMP
Mar 28 10:26:37 router mpd:  PROTOCOMP
Mar 28 10:26:37 router mpd:  MRU 1500
Mar 28 10:26:37 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:37 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:37 router mpd:  MP MRRU 1600
Mar 28 10:26:37 router mpd:  MP SHORTSEQ
Mar 28 10:26:37 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:37 router mpd: pptp0-0: ignoring SetLinkInfo
Mar 28 10:26:39 router mpd: [pt0] LCP: SendConfigReq #22
Mar 28 10:26:39 router mpd:  ACFCOMP
Mar 28 10:26:39 router mpd:  PROTOCOMP
Mar 28 10:26:39 router mpd:  MRU 1500
Mar 28 10:26:39 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:39 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:39 router mpd:  MP MRRU 1600
Mar 28 10:26:39 router mpd:  MP SHORTSEQ
Mar 28 10:26:39 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:41 router mpd: [pt0] LCP: SendConfigReq #23
Mar 28 10:26:41 router mpd:  ACFCOMP
Mar 28 10:26:41 router mpd:  PROTOCOMP
Mar 28 10:26:41 router mpd:  MRU 1500
Mar 28 10:26:41 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:41 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:41 router mpd:  MP MRRU 1600
Mar 28 10:26:41 router mpd:  MP SHORTSEQ
Mar 28 10:26:41 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:43 router mpd: [pt0] LCP: SendConfigReq #24
Mar 28 10:26:43 router mpd:  ACFCOMP
Mar 28 10:26:43 router mpd:  PROTOCOMP
Mar 28 10:26:43 router mpd:  MRU 1500
Mar 28 10:26:43 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:43 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:43 router mpd:  MP MRRU 1600
Mar 28 10:26:43 router mpd:  MP SHORTSEQ
Mar 28 10:26:43 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:45 router mpd: [pt0] LCP: SendConfigReq #25
Mar 28 10:26:45 router mpd:  ACFCOMP
Mar 28 10:26:45 router mpd:  PROTOCOMP
Mar 28 10:26:45 router mpd:  MRU 1500
Mar 28 10:26:45 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:45 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:45 router mpd:  MP MRRU 1600
Mar 28 10:26:45 router mpd:  MP SHORTSEQ
Mar 28 10:26:45 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:47 router mpd: [pt0] LCP: SendConfigReq #26
Mar 28 10:26:47 router mpd:  ACFCOMP
Mar 28 10:26:47 router mpd:  PROTOCOMP
Mar 28 10:26:47 router mpd:  MRU 1500
Mar 28 10:26:47 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:47 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:47 router mpd:  MP MRRU 1600
Mar 28 10:26:47 router mpd:  MP SHORTSEQ
Mar 28 10:26:47 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:49 router mpd: [pt0] LCP: SendConfigReq #27
Mar 28 10:26:49 router mpd:  ACFCOMP
Mar 28 10:26:49 router mpd:  PROTOCOMP
Mar 28 10:26:49 router mpd:  MRU 1500
Mar 28 10:26:49 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:49 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:49 router mpd:  MP MRRU 1600
Mar 28 10:26:49 router mpd:  MP SHORTSEQ
Mar 28 10:26:49 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:51 router mpd: [pt0] LCP: SendConfigReq #28
Mar 28 10:26:51 router mpd:  ACFCOMP
Mar 28 10:26:51 router mpd:  PROTOCOMP
Mar 28 10:26:51 router mpd:  MRU 1500
Mar 28 10:26:51 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:51 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:51 router mpd:  MP MRRU 1600
Mar 28 10:26:51 router mpd:  MP SHORTSEQ
Mar 28 10:26:51 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:53 router mpd: [pt0] LCP: SendConfigReq #29
Mar 28 10:26:53 router mpd:  ACFCOMP
Mar 28 10:26:53 router mpd:  PROTOCOMP
Mar 28 10:26:53 router mpd:  MRU 1500
Mar 28 10:26:53 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:53 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:53 router mpd:  MP MRRU 1600
Mar 28 10:26:53 router mpd:  MP SHORTSEQ
Mar 28 10:26:53 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:55 router mpd: [pt0] LCP: SendConfigReq #30
Mar 28 10:26:55 router mpd:  ACFCOMP
Mar 28 10:26:55 router mpd:  PROTOCOMP
Mar 28 10:26:55 router mpd:  MRU 1500
Mar 28 10:26:55 router mpd:  MAGICNUM ec714a66
Mar 28 10:26:55 router mpd:  AUTHPROTO CHAP MSOFTv2
Mar 28 10:26:55 router mpd:  MP MRRU 1600
Mar 28 10:26:55 router mpd:  MP SHORTSEQ
Mar 28 10:26:55 router mpd:  ENDPOINTDISC [802.1] 00 00 24 c8 21 0c
Mar 28 10:26:57 router mpd: [pt0] LCP: state change Req-Sent --> Stopped
Mar 28 10:26:57 router mpd: [pt0] LCP: LayerFinish
Mar 28 10:26:57 router mpd: [pt0] LCP: parameter negotiation failed
Mar 28 10:26:57 router mpd: [pt0] LCP: LayerFinish
Mar 28 10:26:57 router mpd: [pt0] device: CLOSE event in state UP
Mar 28 10:26:57 router mpd: pptp0-0: clearing call
Mar 28 10:26:57 router mpd: pptp0-0: killing channel
Mar 28 10:26:57 router mpd: [pt0] PPTP call terminated
Mar 28 10:26:57 router mpd: [pt0] IFACE: Close event
Mar 28 10:26:57 router mpd: [pt0] IPCP: Close event
Mar 28 10:26:57 router mpd: [pt0] IPCP: state change Starting --> Initial
Mar 28 10:26:57 router mpd: [pt0] IPCP: LayerFinish
Mar 28 10:26:57 router mpd: [pt0] IFACE: Close event
Mar 28 10:26:57 router mpd: pptp0: closing connection with 206.113.196.2:37087
« Reply #3 on: March 29, 2007, 06:39:49 »
darklogic *
Posts: 45

Just to make sure that you are using the firewall as the VPN server or redirecting to an Internal PPTP server. If you are using the firewall as the main PPTP server the error 619 is a disconnect on the GRE port you need to set a rule on the WAN interface to accept incoming GRE. I saw that you had set a rule under the PPTP tab and I have had issues with that as well. I have found that I have no issues setting the GRE accept incoming on the WAN interface. This will also work for redirecting to any internal routing and remote service server as well. I hope this helps with your issue.
« Reply #4 on: March 29, 2007, 10:12:35 »
mick88 *
Posts: 10

...
 If you are using the firewall as the main PPTP server the error 619 is a disconnect on the GRE port you need to set a rule on the WAN interface to accept incoming GRE.
...
As far as I know, this is done automatically by m0n0wall. So, there is no need for you to define explicit WAN rules to allow port 1723 and GRE protocol.
« Reply #5 on: March 29, 2007, 12:58:49 »
jreineri *
Posts: 6

The firewall is the PPTP server.
« Reply #6 on: March 29, 2007, 20:31:15 »
darklogic *
Posts: 45

Yes you are right mick88, but the rules are only automatically created if you are setting up rules through the natting process. If you look under NAT you will see a check box that says something along the lines of check this box if you want to automatically create rule. He states he is using the firewall as the PPTP server. If you look under the PPTP server setup, there is no automatic rule creation. It even say's Note: don't forget to add a firewall rule to permit traffic from PPTP clients. Maybe this will help with what I am explaining, but yes you are right about rules being automatically created, but only under the NAT section.
« Last Edit: March 29, 2007, 20:35:53 by darklogic »
« Reply #7 on: March 29, 2007, 21:47:38 »
mick88 *
Posts: 10

Yes you are right mick88, but the rules are only automatically created if you are setting up rules through the natting process. If you look under NAT you will see a check box that says something along the lines of check this box if you want to automatically create rule.
I think you mix up things: The checkbox in the NAT screen you mentioned has no effect on the automatic creation of the firewall rules (--> allow 1723 + GRE) when activating the PPTP-VPN server. To check this navigate to <your-monowall-ip>/status.php and look for the lines you see in the attached screenshot. You will see there is no difference whether you check/uncheck the box.


He states he is using the firewall as the PPTP server. If you look under the PPTP server setup, there is no automatic rule creation. It even say's Note: don't forget to add a firewall rule to permit traffic from PPTP clients.
The info about the rule concerns the PPTP-VPN section not the WAN section of the rules. You do not need to add any rules to the WAN section to make the connection work, because this is done automatically when you activate the PPTP-VPN server. You just need some rules to allow inbound traffic from the PPTP-VPN (as the note reminds you of).


* monowall_pptp.jpg (42.88 KB, 611x369 - viewed 2237 times.)
« Reply #8 on: March 30, 2007, 14:47:51 »
jreineri *
Posts: 6

I have a partial answer.  I have been attempting to connect to the VPN from my desktop and laptop at work.  When I stopped at a locak hotspot on the way home I was able to connect to the monowall PPTP VPN easily.  Apparently something in our configuration here at the office is preventing a connection.  The network administrator tells me that there are no outbound filters on our firewall and my WireShark  traces show that port 1723 messages are getting through and replys are being received.  But, I do not know enough about the protocols to decipher the problem.
« Reply #9 on: March 31, 2007, 08:49:03 »
mick88 *
Posts: 10

...
after a much longer delay it changes to:
DialogBox that says:
Disconnected.  Error 619: yada - yada - yada
...

Maybe Chris Buechler's post provides a explanation/solution to your problem (same error code): http://forum.m0n0.ch/index.php/topic,88.0.html#msg340
« Reply #10 on: March 31, 2007, 20:24:04 »
cmb *****
Posts: 851

619 errors are caused by a GRE issue of some sort. The TCP 1723 traffic may be getting through fine, but the GRE traffic isn't. Some NAT implementations completely break GRE, a firewall may be blocking it (your network admin may think permitting all TCP and UDP ports means "no outbound filtering", when there are all kinds of other IP protocols like GRE), a host based firewall may be blocking it, there are a lot of possibilities. Some firewalls, like the Cisco PIX in particular, will break GRE in a default pass all configuration. It's possible to make it work, it just doesn't by default.

To make a long story short, GRE is getting blocked or broken somewhere if you're getting 619 errors.
« Reply #11 on: April 02, 2007, 15:03:45 »
jreineri *
Posts: 6

Thanks, you are exactly right.  On Friday our network admin ran a 'fixup' command on the Cisco PIX firewall and my problem dissappeared immediately.

I believe that the command was: fixup protocol pptp 1723

I beleive that this causes the PIX to 'correct' the embedded GRE messages embedded in the PPTP packets.  The 'correction' is made necessary because of NAT.

Thanks to everyone for the assistance,
Jim

« Reply #12 on: April 04, 2007, 00:28:13 »
darklogic *
Posts: 45

Hey jreineri. Yes that is the problem, I should of asked you what firewall you were behind at work. PIX501 or 506E must have the fixup protocol for PPTP. By default this protocol is disabled. Listed down below is how you configure the PIX, this is just for future reference.

Type the commands as followed in hyper terminal:

en
type in password if any
config t
fixup protocol pptp 1723
show fixup
write mem
reload

These are the commands to allow outbound pptp from behind a PIX firewall.
« Last Edit: April 04, 2007, 00:29:52 by darklogic »
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines