Topic: VPN - Error 619

[jackl]

Sorry Guys it only worked on that occasion it is now back to the usual 619 error no matter what I do with pptpd. This is the annoying thing about this, it does work on occasions.
Had enough I'm off to look at Jespers howto for Open VPN
Regards
Jack

[dave_d]

Hello Jackl,

Referring to the SME 6.0.1-01 built-in VPN system .....

I'm sure that there is a time-out problem somewhere.  I tried to make another VPN connection to my troublesome network last Saturday late P.M. and it failed miserably with the Error 619.  Having had enough I went home for the weekend.  I got back into the office at 0830 this morning and thought I would just try connecting one last time - it worked, just like that!!

Anyway, on a more general note there seems to be another strange thing happening .....

1.  Establish the connection.  From past experience this will (generally) work OK BUT in order to be able to do anything in the newly connected server we need to find it.
2.  On the newly connected Windoze workstation, search for computers.  In the search box specify the name of the server.  Hit search and the server is quickly found.
3.  Double click on the newly found server icon and we get a login box (First question - Why is this?  I just logged onto the server via the VPN?).  Log on as admin/<password> - just to see if everything's working.
4.  Everything OK now - but notice that the user 'fred' who established the VPN is seeing the 'admin' set of files because of the requirement to complete the login box in 3. above.
5.  This is not what we want.  So, kill the connection and junk the VPN definition out of the 'Network and Dial-up connections' area.
6.  Restart the Windoze box for good measure.  Log on as Administrator and create a connection for anyone to use.  Establish the connection as before - but this time the files on the server are immediately available - no additional 'connect as...' step required.
7.  Unfortunately this poses a problem because 'fred', who just logged onto the server from the Administrator account on the Windoze box, cannot see his home directory on the server - just the 'admin' home.  This is not what's required.
8.  Shut everything down and log onto the Windoze box as another user. Re-establish the connection.  Search for the computer - NO COMPUTER!!!!

So, things aren't really doing what they appear to be doing.

Time to check out the log files on the server.  Here I find an intersting couple of lines in the /var/log/meassages file.  Namely ....

Jan 31 09:46:06 cssl-server e-smith[4314]: 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.
Jan 31 09:46:06 cssl-server e-smith[4314]: WARNING: Template processing succeeded for //etc/rc.d/init.d/masq: 1 fragment generated warnings
Jan 31 09:46:06 cssl-server e-smith[4314]:  at /etc/e-smith/events/ip-down/S80conf-masq line 46

I've had a quick look at the offending file and at the resultant /etc/rc.d/init.d/masq file and there seems to be something awry here.  The variable 'OUTERIF' is undefined! As I'm not very good at debugging this stuff when I don't have the luxury of time, perhaps there's an expert out there who can lend his/her wisdom?

So, that seems to be the situation.  In a nutshell the VPN appears to work well and be very stable, but only under certain conditions.  It seems that the NetBIOS side of things is not functioning despite opening ports 137, 138, 138, 445, 1273 with appropriate protocols.  It seems too that once the server files have been made accessible then the particular set of files with which the connection was made remain visible regardless of who logs onto the system.

Comments, anyone???

regards,

Dave

[pistonpilot]

Jan 31 13:57:00 server pptpd[12739]: MGR: Launching /usr/sbin/pptpctrl to handle client
Jan 31 13:57:00 server pptpd[12739]: CTRL: local address = 192.168.1.1
Jan 31 13:57:00 server pptpd[12739]: CTRL: remote address = 192.168.1.35
Jan 31 13:57:00 server pptpd[12739]: CTRL: pppd speed = 460800
Jan 31 13:57:00 server pptpd[12739]: CTRL: pppd options file = /etc/ppp/options.pptpd
Jan 31 13:57:00 server pptpd[12739]: CTRL: Client 68.80.38.0 control connection started
Jan 31 13:57:00 server pptpd[12739]: CTRL: Received PPTP Control Message (type: 1)
Jan 31 13:57:00 server pptpd[12739]: CTRL: Made a START CTRL CONN RPLY packet
Jan 31 13:57:00 server pptpd[12739]: CTRL: I wrote 156 bytes to the client.
Jan 31 13:57:00 server pptpd[12739]: CTRL: Sent packet to client
Jan 31 13:57:00 server pptpd[12739]: CTRL: Received PPTP Control Message (type: 7)
Jan 31 13:57:00 server pptpd[12739]: CTRL: Set parameters to 1525 maxbps, 64 window size
Jan 31 13:57:00 server pptpd[12739]: CTRL: Made a OUT CALL RPLY packet
Jan 31 13:57:00 server pptpd[12739]: CTRL: Starting call (launching pppd, opening GRE)
Jan 31 13:57:00 server pptpd[12739]: CTRL: pty_fd = 5
Jan 31 13:57:00 server pptpd[12739]: CTRL: tty_fd = 6
Jan 31 13:57:00 server pptpd[12739]: CTRL: I wrote 32 bytes to the client.
Jan 31 13:57:00 server pptpd[12739]: CTRL: Sent packet to client
Jan 31 13:57:00 server pptpd[12740]: CTRL (PPPD Launcher): Connection speed = 460800
Jan 31 13:57:00 server pptpd[12740]: CTRL (PPPD Launcher): local address = 192.168.1.1
Jan 31 13:57:00 server pptpd[12740]: CTRL (PPPD Launcher): remote address = 192.168.1.35
Jan 31 13:57:00 server pppd[12740]: pppd 2.4.2b1 started by root, uid 0
Jan 31 13:57:00 server pppd[12740]: Starting negotiation on /dev/pts/0
Jan 31 13:57:00 server pptpd[12739]: CTRL: Received PPTP Control Message (type: 15)
Jan 31 13:57:00 server pptpd[12739]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Jan 31 13:57:00 server pptpd[12739]: GRE: Discarding duplicate packet
Jan 31 13:57:30 server pppd[12740]: LCP: timeout sending Config-Requests
Jan 31 13:57:30 server pppd[12740]: Connection terminated.
Jan 31 13:57:30 server pppd[12740]: Exit.

[pistonpilot]

Let's add to this mess.  The above post is from my messages file.

I can connect to the VPN with no problems using my Verizon Aircard on my laptop.  

I came home and can't get into this VPN using and SMC wireless router.

The router has no settings to allow or disallow PPTP.

I just tried to get into a customer running 6.0 and I've never had trouble getting in.  Today I cannot.  

Prior to this I was using a Clarkconnect 2.2 Office gateway.  Version 3.0 is out and I'm going to put it on a faster machine.  

So, it is the router that is keeping me from delivering what esmith wants.

I wish I had a Clarkconnect box out there to test remotely from this SMC router.  

Maybe I'll throw a linksys on it for giggles.

[pistonpilot]

Sorry Guys it only worked on that occasion it is now back to the usual 619 error no matter what I do with pptpd. This is the annoying thing about this, it does work on occasions.
Had enough I'm off to look at Jespers howto for Open VPN
Regards
Jack

Yes, that is my next project. To add this and test through the same SMC router that does not want to route PPTP to my esmith customers.

For me though it will be easier to put my Clarkconnect back as the gateway.

[jackl]

Just to clarify the situation we have:
There is no problem with vpn to SME server using a stand alone internet PC, or via a Microsoft ISA server or through most routers.
Also no problem with vpn connection from PC behind SME gateway to VPN router or to Microsoft Servers at remote network.
The only time the 619 connection error occurs is when a PC behind an SME Gateway attempts a connection to another remote SME server.
The only thing visible in logs (at remote side)is that there is a problem with the GRE protocol.
 
Regards,
Jack

[raem]

dave_d

> I'm sure that there is a time-out problem somewhere.  

Use iptstate to examine your connections.


> So, things aren't really doing what they appear to be doing.

It sounds like things "are" doing as they are supposed to !
You need to login to your Windows w/s with the same user account you wish to use/view on the remote server. Windows passes your login credentials to the server, which them gives you access rights to ibays etc based on sme server group memberships.
You also (preferably) need to make the VPN connection using the same user acct/password combination ie login to windows as fred using fred's password, then connect via VPN using fred & fred's password.
Prior to that you need to enable VPN access for fred in the sme user accounts screen and make fred a member of certain groups (as required) on the sme server so that the remote VPN connected fred will be allowed to access some ibays etc. Prior to that you need to give ownership of each ibay to a group. Remember the user can be (& most likely needs to be) a member of many groups.

Of course if you login to windows as admin and to VPN as admin you will see ALL the server resources, as admin has automatic access rights to all of those.



> Jan 31 09:46:06 cssl-server e-smith[4314]:
> WARNING: Template processing succeeded
> for //etc/rc.d/init.d/masq: 1 fragment generated warnings
> Jan 31 09:46:06 cssl-server e-smith[4314]:  
> at /etc/e-smith/events/ip-down/S80conf-masq line 46


That template expansion error message suggests you have added some custom templates (or changed templates) and these changes are incorrect. Remove the offending changes you made.

You also need to put your remote servers IP in the WINS setup for the VPN connection (as previously advised in this thread).

Hope that helps.

[dave_d]

Hello Ray,

I used iptstate as suggested (IIRC) in your last post.  That is, I used it when the Error 619s were occurring.  I used it too when the VPN was connected and in both cases the result is nothing - no output other than the heading lines.  This seems to suggest that there's nothing for iptstate to see!

When you read this post it will have been prepared using a VPN connection that gave me 619 last night.  This morning - predictably - it came up with no problem.  So, this seems to indicate that something somewhere is timing out over a fairly long period of time. I found too that increasing the number of allowable PPTP connections after the 619s started enabled me once again to establish a VPN - and this until I had 'exhausted'the number of VPNs again.  This, to me, is another pointer to a timeout problem somewhere.

In fact, as I type this 'over the VPN', I'm using another direct SSL connection to the same server and iptstate is still showing nothing!  'iptables' also shows nothing.  Could this be because it's a 'ServerOnly' installation?  Maybe this has something to do with the Warnings I mentioned?

As for your comments about 'Things "are" doing what they're supposed to', I grant that the scenario you paint is what one would normally do.  However, I've spent the last 25 years working as a software tester and so I always do what one is NOT normally supposed to do and I then observe the effect.  If I create a connection I would expect it always to be fresh - that is, I would expect any credentials passed during the lifetime of the previous connection to be forgotten once the connection is broken.  However, it appears that Windoze remembers them and that means that a 'crossed' connection - whether made deliberately or in error - is bound to the VPN connection definition forever.  Maybe that's what the designers meant - it's just that I would have done it differently!

As for the template thing, I can guarantee that I have made no changes or additions in this area!

Finally, I did indeed add the WINS setup as advised - and it made not one jot of difference!

So I'm still a rather confused bunny!  With help from other patient contributors to this site I've now got OpenVPN up and running and it certainly seems more reliable than the built-in VPN.  However, in some ways the built-in version is more convenient as there's less work to do and there's no need to start adding static routes to the router.

I'll see if I can create a rather more controlled setup in the next few days so that I can persue this in a more orderly fashion.  One of the problems of working with a production server is that one cannot always do the experiments one wishes to make.  Luckily for all of us SMEserver will run on just about anything (for test purposes) and so making a controlled environment for testing in no great shakes.

Regards,

Dave - and thanks for all the input.

[raem]

dave_d

>.....I'm using another direct SSL connection to the > same server and iptstate is still showing
> nothing!  'iptables' also shows nothing.  Could
> this be because it's a 'ServerOnly' installation?  

I think so !


> Maybe this has something to do with the Warnings I mentioned?

I think so also !!


> However, I've spent the last 25 years working as a software tester and so I always do what one is NOT normally supposed to do and I then observe the effect.

Fair enough if you are trying to break or find faults etc. But why use the wrong method when you do in fact have access problems which are being caused by using the wrong method ie passing the wrong authentication ?


> As for the template thing, I can guarantee that I > have made no changes or additions in this area!

That would then seem to be related to the server only configuration !
There may be some issues with your router firewall ??

[dave_d]

Hello Ray,

To be honest I ended up in 'test mode' with a crossed user connection because I had got into zombie mode when creating the connection.  Having tried many times to make the connection without success, I was so surprised when I finally got a username/password prompt that I just automatically typed in the admin/password combination.  That was when I found that things had ended up set in concrete!

Some folks who use this particular server have more than one account - don't ask , it's not my policy!! - and so I can see this situation arising again.

Still.. whichever way we look at things, I think there's a timeout problem here somewhere and I'm $%^&"£&ed if I can find it!!

Regards,
Dave

[smeghead]

G'Day from sunny Perth, Oz

.. warm one day, bloody hot the next

Thought you might like a bit more background reading to aid your PPTP forensics:

http://pptpclient.sourceforge.net/howto-diagnosis.phtml

HTH