Topic: VPN - Error 619

[dave_d]

Looking around the forums it appears that this subject has been done to death - but I haven't yet found a post that says 'this is the solution'. (OTOH, it's well known that I frequently fail to see what's written in front of my eyes!).

Anyway, I set up this 6.0.1-01 server, installed a Vigor 2600V router, set the router up to bypass PPTP traffic, drove back to my office 20 miles away, set up a VPN link and sat back with a satisfied grin.

As part of the job of system management is system testing, I decided to check the robustness of the setup by removing power from the ADSL router at my end - simulating a power cut.

Having restored my end of the setup I tried to re-establish the VPN - no success.  In fact, I have never again been able to establish the VPN.  All I get is the following error report .....

CTRL: I wrote 32 bytes to the client.
CTRL: Sent packet to client
CTRL (PPPD Launcher): Connection speed = 460800
CTRL (PPPD Launcher): local address = 192.168.30.2
CTRL (PPPD Launcher): remote address = 192.168.30.245
pppd 2.4.2b1 started by root, uid 0
Starting negotiation on /dev/pts/1
CTRL: Received PPTP Control Message (type: 15)
CTRL: Got a SET LINK INFO packet with standard ACCMs
GRE: Discarding duplicate packet
LCP: timeout sending Config-Requests
Connection terminated.
Exit.
GRE: read(fd=5,buffer=804d940,len=8196) from PTY failed: status = -1 error = Input/output error
CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
CTRL: Client 80.177.XXX.XXX control connection finished
CTRL: Exiting now
MGR: Reaped child 25197

Can anyone shed any light here (or point me to the correct thread!!)?

Regards,

Dave

[Brave Dave]

I guess you know 619 is incorrect password

Now you might be entering the correct password, but it is not getting to the destination

Have you fiddled with multilink ?
- sometime you need it sometimes you don't

I have had to discard more than one router to achieve reliable pptp - it needs good gear

You can (not sure on the vigour) set some routers (eg. Dynalink RTA300) to bridge mode and expose the sme box directly - many routers allow pptp in this mode but not in .. PPPoE mode - maybe this can help your testing -, but your best bet is to use routers that are tried and true.
I don't use billion or dynalink rta100, but find the netgear dg834 good. now i don't vary and have good success.

i have only experienced the problems others report here when there has been a fault in the line or equipment

[dave_d]

Hello David,

No, I didn't know the specific meaning of the error message - thanks for the info.

However .........  things get curiouser and curiouser.

I left the office for a couple of hours to do another job.  On my return I decided to try the connections again - and guess what? - they worked.

I've changed nothing since this morning and so I'm at a complete loss to know what's going on here.

I noticed, however, that when the VPN was active all other paths to the internet ceased to function AND the remote server is not available in My Network Places.  However, I guess that both of these can be solved with the appropriate settings.

On your comments about the routers I agree entirely.  I had previously tried a DSL-504T and I swapped this out because I thought that it was blocking the GRE protocol messages.  However, in light of the foregoing it's quite possible that it was working - we'll never know!

Here's the 'messages' output that I see now.  You'll see that I first tried to log on as admin and got rejected as I expected.  I then tried to log on as dumolod and got accepted - and this is what should have happened earlier!!! BTW, you don't happen to know what the WARNINGS mean, do you?

 cssl-server pptpd[26930]: MGR: Launching /usr/sbin/pptpctrl to handle client
 cssl-server pptpd[26930]: CTRL: local address = 192.168.30.2
 cssl-server pptpd[26930]: CTRL: remote address = 192.168.30.246
 cssl-server pptpd[26930]: CTRL: pppd speed = 460800
 cssl-server pptpd[26930]: CTRL: pppd options file = /etc/ppp/options.pptpd
 cssl-server pptpd[26930]: CTRL: Client 80.177.XXX.XXX control connection started
 cssl-server pptpd[26930]: CTRL: Received PPTP Control Message (type: 1)
 cssl-server pptpd[26930]: CTRL: Made a START CTRL CONN RPLY packet
 cssl-server pptpd[26930]: CTRL: I wrote 156 bytes to the client.
 cssl-server pptpd[26930]: CTRL: Sent packet to client
 cssl-server pptpd[26930]: CTRL: Received PPTP Control Message (type: 7)
 cssl-server pptpd[26930]: CTRL: Set parameters to 1525 maxbps, 64 window size
 cssl-server pptpd[26930]: CTRL: Made a OUT CALL RPLY packet
 cssl-server pptpd[26930]: CTRL: Starting call (launching pppd, opening GRE)
 cssl-server pptpd[26930]: CTRL: pty_fd = 5
 cssl-server pptpd[26930]: CTRL: tty_fd = 6
 cssl-server pptpd[26930]: CTRL: I wrote 32 bytes to the client.
 cssl-server pptpd[26930]: CTRL: Sent packet to client
 cssl-server pptpd[26931]: CTRL (PPPD Launcher): Connection speed = 460800
 cssl-server pptpd[26931]: CTRL (PPPD Launcher): local address = 192.168.30.2
 cssl-server pptpd[26931]: CTRL (PPPD Launcher): remote address = 192.168.30.246
 cssl-server pptpd[26930]: CTRL: Received PPTP Control Message (type: 15)
 cssl-server pptpd[26930]: CTRL: Got a SET LINK INFO packet with standard ACCMs
 cssl-server pppd[26931]: pppd 2.4.2b1 started by root, uid 0
 cssl-server pppd[26931]: Starting negotiation on /dev/pts/1
 cssl-server pptpd[26930]: GRE: Discarding duplicate packet
 cssl-server pptpd[26930]: CTRL: Received PPTP Control Message (type: 15)
 cssl-server pptpd[26930]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
 cssl-server pppd[26931]: No CHAP secret found for authenticating admin
 cssl-server pppd[26931]: CHAP peer authentication failed for admin
 cssl-server pptpd[26930]: CTRL: Received PPTP Control Message (type: 15)
 cssl-server pptpd[26930]: CTRL: Got a SET LINK INFO packet with standard ACCMs
 cssl-server pppd[26931]: Connection terminated.
 cssl-server pppd[26931]: Exit.
 cssl-server pptpd[26930]: GRE: read(fd=5,buffer=804d940,len=8196) from PTY failed: status = -1 error = Input/output error
 cssl-server pptpd[26930]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
 cssl-server pptpd[26930]: CTRL: Client 80.177.XXX.XXX control connection finished
 cssl-server pptpd[26930]: CTRL: Exiting now
 cssl-server pptpd[22384]: MGR: Reaped child 26930
 cssl-server pptpd[26934]: MGR: Launching /usr/sbin/pptpctrl to handle client
 cssl-server pptpd[26934]: CTRL: local address = 192.168.30.2
 cssl-server pptpd[26934]: CTRL: remote address = 192.168.30.245
 cssl-server pptpd[26934]: CTRL: pppd speed = 460800
 cssl-server pptpd[26934]: CTRL: pppd options file = /etc/ppp/options.pptpd
 cssl-server pptpd[26934]: CTRL: Client 80.177.XXX.XXX control connection started
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 1)
 cssl-server pptpd[26934]: CTRL: Made a START CTRL CONN RPLY packet
 cssl-server pptpd[26934]: CTRL: I wrote 156 bytes to the client.
 cssl-server pptpd[26934]: CTRL: Sent packet to client
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 7)
 cssl-server pptpd[26934]: CTRL: Set parameters to 1525 maxbps, 64 window size
 cssl-server pptpd[26934]: CTRL: Made a OUT CALL RPLY packet
 cssl-server pptpd[26934]: CTRL: Starting call (launching pppd, opening GRE)
 cssl-server pptpd[26934]: CTRL: pty_fd = 5
 cssl-server pptpd[26934]: CTRL: tty_fd = 6
 cssl-server pptpd[26934]: CTRL: I wrote 32 bytes to the client.
 cssl-server pptpd[26934]: CTRL: Sent packet to client
 cssl-server pptpd[26935]: CTRL (PPPD Launcher): Connection speed = 460800
 cssl-server pptpd[26935]: CTRL (PPPD Launcher): local address = 192.168.30.2
 cssl-server pptpd[26935]: CTRL (PPPD Launcher): remote address = 192.168.30.245
 cssl-server pppd[26935]: pppd 2.4.2b1 started by root, uid 0
 cssl-server pppd[26935]: Starting negotiation on /dev/pts/1
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 15)
 cssl-server pptpd[26934]: CTRL: Got a SET LINK INFO packet with standard ACCMs
 cssl-server pptpd[26934]: GRE: Discarding duplicate packet
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 15)
 cssl-server pptpd[26934]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
 cssl-server kernel: divert: not allocating divert_blk for non-ethernet device ppp0
 cssl-server pppd[26935]: Using interface ppp0
 cssl-server pppd[26935]: CHAP peer authentication succeeded for dumolod
 cssl-server pppd[26935]: MPPE 128-bit stateless compression enabled
 cssl-server /etc/hotplug/net.agent: assuming ppp0 is already up
 cssl-server pppd[26935]: found interface eth0 for proxy arp
 cssl-server pppd[26935]: local  IP address 192.168.30.2
 cssl-server pppd[26935]: remote IP address 192.168.30.245
 cssl-server e-smith[26949]: Processing event: ip-up.pptpd ppp0 /dev/pts/1 460800 192.168.30.2 192.168.30.245 pptpd
 cssl-server e-smith[26949]: Running event handler: /etc/e-smith/events/ip-up.pptpd/S70pptp-interface-access
 cssl-server /etc/e-smith/events/ip-up.pptpd/S70pptp-interface-access[26950]: /home/e-smith/configuration: OLD pptpd=service|Interfaces||StartIP|3232243445|sessions|6|status|enabled
 cssl-server /etc/e-smith/events/ip-up.pptpd/S70pptp-interface-access[26950]: /home/e-smith/configuration: NEW pptpd=service|Interfaces|ppp0|StartIP|3232243445|sessions|6|status|enabled
 cssl-server e-smith[26949]: S70pptp-interface-access=action|Event|ip-up.pptpd|Action|S70pptp-interface-access|Start|1106656298 962197|End|1106656299 441596|Elapsed|0.479399
 cssl-server e-smith[26949]: Running event handler: /etc/e-smith/events/ip-up.pptpd/S80conf-masq
 cssl-server e-smith[26949]: WARNING in /etc/e-smith/templates//etc/rc.d/init.d/masq/00Definitions: Use of uninitialized value in concatenation (.) or string at /etc/e-smith/templates//etc/rc.d/init.d/masq/00Definitions line 5.
 cssl-server e-smith[26949]: WARNING: Template processing succeeded for //etc/rc.d/init.d/masq: 1 fragment generated warnings
 cssl-server e-smith[26949]:  at /etc/e-smith/events/ip-up.pptpd/S80conf-masq line 46
 cssl-server e-smith[26949]: S80conf-masq=action|Event|ip-up.pptpd|Action|S80conf-masq|Start|1106656299 441816|End|1106656300 349574|Elapsed|0.907758
 cssl-server e-smith[26949]: Running event handler: /etc/e-smith/events/ip-up.pptpd/S85adjust-masq
 cssl-server e-smith[26949]: S85adjust-masq=action|Event|ip-up.pptpd|Action|S85adjust-masq|Start|1106656300 349771|End|1106656300 592954|Elapsed|0.243183
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 5)
 cssl-server pptpd[26934]: CTRL: Made a ECHO RPLY packet
 cssl-server pptpd[26934]: CTRL: I wrote 20 bytes to the client.
 cssl-server pptpd[26934]: CTRL: Sent packet to client
 cssl-server pptpd[26934]: CTRL: Received PPTP Control Message (type: 5)
 cssl-server pptpd[26934]: CTRL: Made a ECHO RPLY packet
 cssl-server pptpd[26934]: CTRL: I wrote 20 bytes to the client.
 cssl-server pptpd[26934]: CTRL: Sent packet to client
[root@cssl-server log]#

[smeghead]

I use the DG834 too, and find them genrally excellent for the $$$.

They support 1 vpn passthrough session; otherwise use port forwarding (for port 1723) for pptp connections.

How many pptp sessions do you have nominated in the Server Manager?  I find that it can take a while for an old session to be completely released so am in the habit of providing a couple more than necessary to compensate; otherwise your blocked.

HTH

[Knuddi]

Have you considered using OpenVPN? I have made a howto for that as I found the build-in PPTP much to unstable and unpredictable. I have it running for 3 months now and it has never let me down. The clients I use are Win2k/XP.

See:
http://sme.swerts-knudsen.dk/howtos/howto_30.htm

Rgds,
Jesper

[raem]

Do
iptstate
to see what sessions are open.
As smeghead says, perhaps you don't have enough sessions specified in server manager and there are sessions that are still timing out after "disconnection".

admin will not be able to connect via VPN unless you enable VPN for that user account.

[dave_d]

Thanks for everyone's help, I now have two serviceable ways to make a stable VPN - the method using the standard VPN stuff in the 6.0.1-01 distribution AND the OpenVPN method.  Using either method I can create and maintain good connections through various routers - very satisfying.

However - there's always one of these when dealing with Windoze - I can't 'see' the server to which I am connected in the Network Neighbourhood.  I've opened ports 137-139 for the standard VPN connection, and I don't see any special port requirements for the OpenVPN implementation.  I'm trying to connect an XP-SP2 workstation.

Could this be anything to do with Windoze domains? Or maybe it's a NetBIOS problem? The PC that I'm trying to connect to the remote server is already member of another, unconnected domain.

Any suggestions welcome - this whole exercise is beginning to drag a bit!

Regards,

Dave

[smeghead]

.. for your VPN connection only nominate the remote server as the WINS server.

HTH

[dave_d]

Hello Smeghead,
Thanks for the suggestion - didn't work, I'm afraid!

I tried nominating both the external router IP and the remote server internal IP as WINS server using both the built-in VPN stuff AND the OpenVPN setup.  In none of these cases could I get to see the remote network under My Network Places (or whatever it's called today!).

I've also played around with all the NetBIOS over TCP/IP settings but the network remains stubbornly invisible.  AAaarrrgghhh!!!!!

(Calming down ..... ) However, by specifically searching for the computer (remote server) by name it's found almost immediately.  From that point onwards it can be used as normal.  Unfortunately for me my client is not satisfied with this solution.  He insists that it's got to be just like the Windoze network he just left - understandable, I s'pose!

Does anyone have any more suggestions?

Regards,

Dave

[smeghead]

.. this issue is not specific to SME as it is a relatively common experience on pure Windows networks.  Unfortunately, its one of those mongrel problems for which there is no magical panacea.

Most of the time I find that the w/s needs a reload of Windows to resolve the prob; can you test with a different system that has a clean Windows build?

On reflection maybe try this ...

What your trying to do is Netbios browsing using SMB communication.  This browsing function relies on a 'browse master' computer to maintain the list of available systems on the network segment.  James Price has an advanced worksgroup contrib (with a little help from me) that allows you to improve the SME box's chance of becoming the browse master on the network.  This process occurs via an election held between all the systems on the network.  Servers are by default more likely to be elected the master but it doesn't hurt to up the odds.

If you can get the SME box to be the browse master it may solve this prob.

HTH

[pistonpilot]

Here is a universal constant with SME 6.X.  You will get unpredictable results when you try to VPN into an e-smith box from another e-smith box with the VPN running.

I'm not talking about the IPSEC, only the PPTP.  If you turn off your VPN services

services pptpd

You will find you can VPN in when you turn it off, and sometimes you need to recycle the VPN service on the server

services pptdp restart

[jackl]

Our network uses sme6.0 as gateway and server we support many different networks in our area including linux, microsoft, netware, solaris etc. VPN connections to our SME servers are the only ones that give trouble, despite all the comments here, this is one that's not a Microsoft problem, as we can connect to any of our microsoft networks using VPN and terminal services through our SME gateway without any problems what so ever. The problem occurs only on a connection from a workstation behind SME to another external SME server. What is truely amazing about this problem is that occasionally the connection actually works, initially we thought this was time related, however this also proved in correct as the times it actually works, appears to be purely random.
It also has absolutely nothing to do with the routers we use as all these networks worked fine when they were running SME 5.5. The logs at the receiving side show a problem with the GRE protocol:
Jan 29 22:42:00 server01 pptpd[20046]: GRE: read(fd=6,buffer=80559a0,len=8260) from network failed: status = -1 error = Protocol not available
Jan 29 22:42:00 server01 pptpd[20046]: CTRL: GRE read or PTY write failed (gre,pty)=(6,5)
Jan 29 22:42:00 server01 pptpd[20046]: CTRL: Client 213.170.77.102 control connection finished
Jan 29 22:42:00 server01 pptpd[20046]: CTRL: Exiting now
Jan 29 22:42:00 server01 pptpd[3192]: MGR: Reaped child 20046
Jan 29 22:42:00 server01 pppd[20047]: Modem hangup
Jan 29 22:42:00 server01 pppd[20047]: Connection terminated.
Also off the top of my head to David Bray it is error 691 that relates to incorrect passwords not 619 however I may stand to be corrected on this.
Despite this having the experience of maintaining many different networks, SME is a magnificent product, mainly due to the many talented people who contrib so much in the forums, so I apologise for my only complaint of SME6.0, Guys workstation VPN behind SME to another SME server is totally unpredictable you may or maynot get connected (usually not).

[pistonpilot]

The problem occurs only on a connection from a workstation behind SME to another external SME server. What is truely amazing about this problem is that occasionally the connection actually works, initially we thought this was time related, however this also proved in correct as the times it actually works, appears to be purely random.

This is what I am telling you.  Trying to VPN using pptp via a SME server to another SME server running VPN will not work.  Humour me, turn off your PPTPD on the network you are originating from and it will sail through.

I found this out the hard way.

No one has come up with a fix.

[jackl]

pistonpilot
Thanks, Amazing that actually works, sorry for not reading your post more carefully. I've tried all sorts of combinations of things to try and achieve a work around or fix for this problem, this has opened a new avenue to try and figure out how this problem occurs, or perhaps it is such a handy workaround maybe I might not bother. Is this problem present in the new 6.5 beta version?
Many thanks again, pistonpilot.

Regards,
Jack

[pistonpilot]

pistonpilot
Thanks, Amazing that actually works, sorry for not reading your post more carefully. I've tried all sorts of combinations of things to try and achieve a work around or fix for this problem, this has opened a new avenue to try and figure out how this problem occurs, or perhaps it is such a handy workaround maybe I might not bother. Is this problem present in the new 6.5 beta version?
Many thanks again, pistonpilot.

Regards,
Jack

I don't know anything about 6.5 - I haven't used it yet.  I'm also a ClarkConnect Reseller and that is how I figured this out.  I hashed it out with ClarkConnect , they have an excellent product and very good support.

For what it is worth, I go through my ClarkConnect box from home to E-Smith VPN's all the time.  I don't have to turn off my PPTP VPN on the ClarkConnect to make it work.  Go figure.

Howard