Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: Anonymous on July 18, 2004, 10:49:40 PM
-
One of the really neat features of SME has been the PPTP support, allowing remote VPN access to the network where an IPSEC configuration is not possible or desirable. This is particularly true for servers with dynamic IP addresses.
Up to and including release 5.5, I have never had problems with PPTP. Since E-smith 5.6 all the way to SME 6.01, pptp reliability has been a hit-or-miss affair, and my experience has been the following:
a) pptp does not work at *all* with SME >5.5 installed on AMD processors.
b) pptp works *sometimes* on Intel boxes, and sometimes not - on about 50% of the boxes it works. I have two sites with SME 6.0.1, identical hardware, identical internet routers, and using the same ISP; remote pptp access on one site is very reliable, but on the other site I can never connect at all!
The majority of error messages from the client connections are "619" errors - the server logs typically contain "GRE"-related error messages such as the one I got today after upgrading an Intel machine to a newer processor (and reinstalling SME 6.0.1):
Jul 18 14:51:43 gateway pptpd[3438]: GRE: xmit failed from decaps_hdlc: Operation not permitted
Jul 18 14:51:43 gateway pptpd[3438]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
From reviewing the forums, it appears to me that many of us have similar problems with pptp. Since I consider pptp to be a major feature of SME, I would like to participate in a project to fix pptp on SME under the guidance of an SME guru - I am a relative Linux newbie and do not have the skills to do so myself, but I am willing to spend whatever time is necessary debugging and testing pptp on Intel and AMD architectures. Are there any interested gurus?
-
Hi,
This sounds like another great opportunity to create a small team addressing this 'issue'.
How about creating a wiki section for this, it real easy and every subscriber can do so. Ofcource other members need to step up too and form a team.
Please take a look here: http://no.longer.valid/phpwiki/index.php/Volunteering
Thanks,
RequestedDeletion
-
.. I know you said identical routers but do they have the same firmware; some Netgear routers, for example, have flakey pptp passthrough unless using the latest firmware.
HTH
-
> pptp does not work at *all* with SME >5.5 installed on AMD processors.
There were specific mppe modules for AMD processors for v5.6U4 & onwards, I assume they have been rolled into the v6.0 and later releases.
> remote pptp access on one site is very reliable,
> but on the other site I can never connect at all!
Doesn't that suggest to you that the "problems you have" are not really an underlying sme server issue, but more like a configuration or hardware issue.
-
Ray,
Have been using pptp in 5.6, 6 with no problem. Am using XP PRO. Had to turn on Negotiate Multi-link for single link connections. This is an option when you create a vpn connection. It is under Properties -> Networking -> Settings -> Negotiate Multi-link for single link connections in the created vpn connection. This option fixed all the problems I was having with AMD processors and PPTP VPNs.
Just something that worked for me.
Marco
-
Doesn't that suggest to you that the "problems you have" are not really an underlying sme server issue, but more like a configuration or hardware issue.
Ray,
While not being a Linux guru, I am well experienced in installing hardware and configuring SME; I have verified and re-verified that both servers *are* properly (and identically, except for site-specific details) configured. Being careful not to have "tunnel vision", I have even invited other friends experienced with SME to review the configurations for stuff I may have overlooked, but they have not found anything wrong either. That is the source of my frustration because there is no *obvious* reason pptp should work on one server and fail on another. Yesterday I upgraded yet another server from Mitel SME 6.0 Final to SME 6.01; no other configuration changes, but pptp is now broken when it worked just prior to the upgrade. I cannot help but wonder whether there is a subtle bug in the upgrade procedure because "fresh" installs seem to work better. However, it is time-consuming to have to completely redo a server every time a new release comes along.
As RequestedDeletion suggested, I am going to open a wiki on this topic. If I am proven wrong and there is in fact some configuration or hardware issue causing pptp to fail, I shall be a very happy to find it and publish my mea culpa and the solution, because I think there are a lot of other similarly frustrated pptp users out there.
-
Dear pwalter
It is more likely the router or ISP or Windows client settings that are the problem rather than sme.
As someone said, v6 is "more strict" and "less than good" settings in your VPN client which work OK for one version of sme may not work OK for another version.
Of course there could be an underlying issue in sme code, your experience upgrading from v6.0 to v6.0.1 is a possible indication of a problem. I would have thought that that upgrade would be OK as the two versions are so very similar.
There have been some very good solutions that users have posted in these forums, have you gone through them all ?
-
Ray,
The router(s) are always configured in "bridged" mode and the pppoe connections, where necessary, are handled by SME. In some cases, the servers have a static ip address. I have tried all the solutions posted in the forums - again, some remote servers work correctly, and some do not, all being accessed from the *same* windows client, going through the same SME server firewall. in any case, if it really was a *client* problem, I do not think that would not explain the "GRE" errors in the system log on the destination servers - unless my personal SME server is not passing through some connections properly. I really do not know enough about the "GRE" errors to be able to identify whether the problem is on the Windows client or on the target server. I should point out that connections to "real" Windows servers with pptp work 100% of the time.
Peter
-
Dear pwalter
re:
GRE: xmit failed from decaps_hdlc: Operation not permitted
CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
A search on google finds plenty of those type of log entries, again suggestive that other people using different OS's have similar VPN problems.
Also suggestive of a connection problem rather than strictly a server bug issue.
This post had a bit right at the end about mru settings, I don't know if that is related to your problems at all.
http://www.hollenback.net/index.php/RedHat8PptpServer
This post had a comment about:
"You get an operation not permitted error if you have a filter rule on the server that drops the GRE packet in the OUTPUT chain."
http://lists.netfilter.org/pipermail/netfilter-devel/2002-December/009911.html
Read all the search results at Google, they may give you some clues.
-
Ray,
Thank you for continuing this thread, and for the links you posted. However, I had thoroughly googled this problem before posting and there does not seem to be an *obvious* solution. I agree that there seems to be a "connection" problem - but I think it is in SME's firewall NAT code - either ingoing or outgoing, rather than, say, a problem in the code for the pptpd daemon. I rather suspect it is in the NATting of the outgoing packets from desktop client through my personal SME 6.01 server.
All the SME configurations are "stock" in terms of the firewall configurations and pptpd connection parameters. There are no "extra" filtering rules in the firewall configurations.
Here are some additional links I abstracted from the 'net:
http://lists.slug.org.au/archives/slug/2004/01/msg00585.html
- the thread suggests that the firewall or ISP is blocking GRE packets
- author confirms that he can connect to another pptpd server with identical pptpd configuration options
http://ccfaq.valar.co.uk/modules.php?name=News&file=article
- author(s) are using a different distribution - clarkconnect, but clarkconnect uses the same PoPToP pptpd setup, AFAIK
- author suggests using updated rpms from www.poptop.org
http://lists.contribs.org/mailman/public/devinfo/msg06683.html
- author posted to devinfo with the same problem on SME, was redirected to bugs list
http://lists.netfilter.org/pipermail/netfilter/2003-June/045107.html
http://lists.netfilter.org/pipermail/netfilter-devel/2003-September/012306.html
- threads suggest that the problem is related to firewall NAT
http://sourceforge.net/mailarchive/message.php?msg_id=8990474
- suggests that the incoming packets are being blocked, use tcpdump on server to analyse incoming packets
http://pptpclient.sourceforge.net/howto-diagnosis.phtml#write_eperm
Symptom: write to the GRE socket fails with EPERM.
Diagnosis: iptables rules (such as for a firewall configuration) do not allow the interface to emit GRE packets.
Solution: locate the rule that prevents the write, or add a rule to cover it, and retry the tunnel.
To test the possibility that it is the "outgoing" packets from my desktop machine going through my SME firewall that are related to the problem, I disconnected from my DSL network and used a dial-up account (from the same ISP) to connect to various remote SME servers. Result: of seven tests, two of which reliably connected through my SME server, six connected properly via the dial-up account. That indicates to me that the outbound NAT may be the source of the problem.
I think that the only way to truly identify the cause of this problem is to analyse the traffic between the SME servers involved in the connection. My understanding is than one can use "tcpdump" to dump the connection traffic, but while I have seen some instructions on how to use tcpdump to capture the traffic on the target server, I am unsure of how to dump the traffic on the originating server. Is there a tcpdump guru out there who is willing to help?
Peter
-
I can confirm that SME 6.0x is, for me, unreliable regarding pptp connections. I have tested this with approximately a dozen servers with the following results:
I am consistently unable to connect via pptp when the workstation goes out through an SME 6.0x server to connect to another SME 6.0x server. This has been tested with Windows XP and Windows 2000 workstations. I have used the recommended workstation settings from this forum and tried virtually every conceivable alternative setting as well.
When connecting through an SME 6.01-01 server to a 5.6 or 5.5 server, the connections work reliably.
Lastly, connections are no problem when I by-pass the SME server on the outbound side, and go directly through the ISP connection - regardless of the target server's processor type (AMD/Intel) or version 5.5, 5.6, 6.0b3, 6.0 final, or 6.01-01. This is such a pain that I will only use pptp in an emergency, by-passing SME and then re-connecting the server afterwards.
I am curious if others have had the same problems, with emphasis on the SME to SME connection. I think some of those who report good results with pptp are not going through one SME server to get to another, but I could be wrong.
I would appreciate feedback from any other pptp users.
Thanks,
jim
-
Jim,
It is comforting to know that my experience with pptp and SME-to-SME connections is not unique.
If there are outher users out there with SME pptp connection problems, I would be glad to hear from you - especially if you test "bypassing" your SME server and the problem disappears.
Peter
-
Jim & Peter here is some feedback.......
My posting from bug tracker:
>>>>>>
I have SME 6.0.1-01 (upgraded from 5.6) running at home for many months. Work was SME 5.6...no PPTP problems. Last week, upgraded work SME to 6.0.1-01. I can no longer PPTP from XP Pro behind my home SME server..error 619. Others users with hardware firewalls (or no firewall) have no problem connecting to the newly upgraded server. I have been using pptp vpn from home (cox cable modem) to work (cox fiber 9mb) for years until now. There IS a problem using PPTP with two 6.0.1-01 SME servers in the mix.
<<<<<<<
I got around the problem by changing my outbound (home) external IP address on SME. I have Cox @work (in my home) which provides 3 static IP addresses. I changed from IP1 to IP2..pptp worked. I am back on IP1 and pptp has been connected for several hours. I don't understand why this works, but felt it might help the forum. Should I post this to the bug tracker?
Hopefully this annoyance with 6.0.1-01 will be figured out soon. I was about to replace my SME with a different server.
ryan
-
Ryan,
Welcome to the club - that now makes *three* of us with the same problem. I am happy you found a work-around; it would not work for me because I have a dynamic ip address.
Is there anyone out there who is knowledgeable about tcpdump that can instruct me how to capture the pptp traffic on each server, and help with the analysis of the capture data?
Peter
-
Peter,
Maybe you could remove a nic and hook up a modem..get online, see if you can make a connection then if so, put the nic back in...it might give you similar results...worth a try if you have a modem and a dial up account.
ryan
-
Ryan,
Like Jim, If I disconnect the SME server from the router and hook up my computer directly to the DSL router, pptp access works fine, as it does if I use a dial-up connection instead of the DSL line. The problem manifests itself when going through my SME6.01 box. I have already changed the NICs in the box, but no joy.
Peter
-
Jim & Peter here is some feedback.......
My posting from bug tracker:
>>>>>>
I have SME 6.0.1-01 (upgraded from 5.6) running at home for many months. Work was SME 5.6...no PPTP problems. Last week, upgraded work SME to 6.0.1-01. I can no longer PPTP from XP Pro behind my home SME server..error 619. Others users with hardware firewalls (or no firewall) have no problem connecting to the newly upgraded server. I have been using pptp vpn from home (cox cable modem) to work (cox fiber 9mb) for years until now. There IS a problem using PPTP with two 6.0.1-01 SME servers in the mix.
<<<<<<<
I got around the problem by changing my outbound (home) external IP address on SME. I have Cox @work (in my home) which provides 3 static IP addresses. I changed from IP1 to IP2..pptp worked. I am back on IP1 and pptp has been connected for several hours. I don't understand why this works, but felt it might help the forum. Should I post this to the bug tracker?
Hopefully this annoyance with 6.0.1-01 will be figured out soon. I was about to replace my SME with a different server.
ryan
-
I meant hooking up a modem to the SME server and use it in dialup mode...your PC will still go through SME as it does now...just much slower, but your pptp might connect using the modem on SME.
Ryan
-
Ryan,
hmmm... I haven't owned an external modem in years, and the internal modem in the server is not supported (winmodem). But, even if I *did* get it to work with a dial-up connection, that would not be suitable for production use - I need my DSL connection to work with pptp because I need the bandwidth to transfer large files. 56kbit/s will not cut it.
Peter
-
Peter,
When I switched from IP1 to IP2, pptp started working. It continued to work after switching from IP2 to IP1....I am thinking if you get pptp to work with dialup on SME, you it might still work when you reinstall the nic card.............
ryan
-
Ryan,
When you change IPs, you have to re-configure the server, am I correct? I wonder if there is something that gets fixed when you change IPs and the server re-creates the templates.
Just an Idea.
Marco
-
I have been struggling for 3 months to get my pptp working, ever since upgrading to ver 6.
I have searched every post I can find and have made a few of my own, and tried hundreds of the suggestion, still with no joy.
It seems to me that VPN does not work in v6.
This is frustrating, as I used it extensively earlier.
-
Brian,
PPTP VPN works fine on SME 6 as long as your client is not passing traffic through a SME 6 server to the PPTP SME 6 VPN server. I don't think their is a solution..I personally am giving up and installing IPCop at my home (keeping SME 6 for services).
good luck,
ryan
-
Ryan,
I had no problems using v5.6, but since upgrading to v6.01 I have not been able to connect.
I believe it may have something to do with the fact that I have an AMD Athlon XP 2800+ CPU.
I am connecting directly to my server - I cannot even connect directly.
It connects, verifies passwords and then stops when registering the computer on the network.
The error messages are not consistent either, but essentially are similar to the following:
CTRL: Received PPTP Control Message (type: 15)
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Aug 6 08:37:50 fs1 kernel: divert: not allocating divert_blk for non-ethernet device ppp1
Aug 6 08:37:50 fs1 pppd[8833]: Using interface ppp1
Aug 6 08:37:50 fs1 /etc/hotplug/net.agent: assuming ppp1 is already up
Aug 6 08:37:50 fs1 modprobe: modprobe: Can't locate module ppp-compress-18
Aug 6 08:37:50 fs1 pppd[8833]: MPPE required, but kernel has no support.
Aug 6 08:37:50 fs1 pppd[8833]: CHAP peer authentication succeeded for john
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: Received PPTP Control Message (type: 15)
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Aug 6 08:37:50 fs1 pppd[8833]: Connection terminated.
Aug 6 08:37:50 fs1 pppd[8833]: Connect time 0.1 minutes.
Aug 6 08:37:50 fs1 pppd[8833]: Sent 0 bytes, received 44 bytes.
Aug 6 08:37:50 fs1 pppd[8833]: Connect time 0.1 minutes.
Aug 6 08:37:50 fs1 pppd[8833]: Sent 0 bytes, received 44 bytes.
Aug 6 08:37:50 fs1 pppd[8833]: Exit.
Aug 6 08:37:50 fs1 kernel: divert: no divert_blk to free, ppp1 not ethernet
Aug 6 08:37:50 fs1 pptpd[8832]: GRE: read(fd=5,buffer=804d940,len=8196) from PTY failed: status = -1 error = Input/output error
Aug 6 08:37:50 fs1 /etc/hotplug/net.agent: NET unregister event not supported
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: Client 192.168.1.101 control connection finished
Aug 6 08:37:50 fs1 pptpd[8832]: CTRL: Exiting now
Aug 6 08:37:50 fs1 pptpd[3020]: MGR: Reaped child 8832
I have tried all possible client configuratons.
-
did you play around with your kernel ?
try setting up a fresch sme server install and see if it works. it saves you time while looking after what is causing this.
peter
-
no, but I am trying a ew kernel now
Thanks
-
Has anyone found a solution on this subject yet ?
I am willing to help, since my connections are intermittend as well. Sometimes it works, sometimes it doesn't work.
-
I am using the community release 6.0.1 for outbound PPTP connecdtions to other SME servers and a SME6.0 server for inbound PPTP connections.
Outbound problems for me occur if I stop a pptp connection and try to restart it. I don't know if a connection needs to be timed out before a new one can start. I work around this problem by using a wireless connection that I have that bypasses the SME server and gets me out to the Internet directoly.
Inbound has only been a problem for one user who has Windows 98 at home. Her configuration worked with an older version of SME, but not with the 6.0 version. Unfortunately I'm not sure which version she was dialing in that worked...probably 5.6...
-
> I don't know if a connection needs to be timed out > before a new one can start.
I believe Charlie said there is a 10 minute timeout (or thereabouts) which I think can be adjusted, search the old posts on VPN.
-
In my case its not a timeout issue.
Came in this morning, tried to make a connection, bu to no avail, when I use smoothwall as a router instead of SME 6 I get solid connections every time.
I am considering going for either m0n0wall, smoothwall or ipcop as a router.
M0n0 seems quite nice sinec it does traffic shaping as well.
-
trying to vpn from xp machine through 6.01 gateway to another 6.01 box. No luck yet others are working.
Have three boxes now behaving the same as described above after upgrading from 5.6 to 6.01.
Log files show
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: MGR: Launching /usr/sbin/pptpctrl to handle client
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: local address = 10.0.0.254
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: remote address = 10.0.0.246
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: pppd speed = 460800
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: pppd options file = /etc/ppp/options.pptpd
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Client 203.220.28.66 control connection started
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Received PPTP Control Message (type: 1)
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Made a START CTRL CONN RPLY packet
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: I wrote 156 bytes to the client.
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Sent packet to client
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Received PPTP Control Message (type: 7)
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Set parameters to 1525 maxbps, 64 window size
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Made a OUT CALL RPLY packet
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Starting call (launching pppd, opening GRE)
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: pty_fd = 5
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: tty_fd = 6
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: I wrote 32 bytes to the client.
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Sent packet to client
Jan 13 09:55:12 sff-sme-01 pptpd[8901]: CTRL (PPPD Launcher): Connection speed = 460800
Jan 13 09:55:12 sff-sme-01 pptpd[8901]: CTRL (PPPD Launcher): local address = 10.0.0.254
Jan 13 09:55:12 sff-sme-01 pptpd[8901]: CTRL (PPPD Launcher): remote address = 10.0.0.246
Jan 13 09:55:12 sff-sme-01 pppd[8901]: pppd 2.4.2b1 started by root, uid 0
Jan 13 09:55:12 sff-sme-01 pppd[8901]: Starting negotiation on /dev/pts/2
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Received PPTP Control Message (type: 15)
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: GRE: read(fd=6,buffer=80559a0,len=8260) from network failed: status = -1 error = Protocol not available
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: GRE read or PTY write failed (gre,pty)=(6,5)
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Client 203.220.28.66 control connection finished
Jan 13 09:55:12 sff-sme-01 pptpd[8900]: CTRL: Exiting now
Jan 13 09:55:12 sff-sme-01 pptpd[28817]: MGR: Reaped child 8900
Jan 13 09:55:12 sff-sme-01 pppd[8901]: Modem hangup
Jan 13 09:55:12 sff-sme-01 pppd[8901]: Connection terminated.
Jan 13 09:55:12 sff-sme-01 pppd[8901]: Exit.
any help would be appreciated!
-
I had no problems using v5.6, but since upgrading to v6.01 I have not been able to connect.
I believe it may have something to do with the fact that I have an AMD Athlon XP 2800+ CPU.
Correct.
Aug 6 08:37:50 fs1 pppd[8833]: MPPE required, but kernel has no support.
[...]
I have tried all possible client configuratons.
Your problem isn't at the client end.
You need to have a ppp-modules RPM installed which matches the architecture of your kernel. That probably means the 'athlon' variant of each, but the 'i686' of both would also work.
You should be able to do "modprobe ppp_mppe" without error.
-
I also have some problems with pptp from behind SME 6.01 (at home) to SME 6 (at work), but the problem seams to be related to winXPpro. Connecting from a win98SE does not give any problems at all. From an XPpro I sometimes can connect. If I succeed in connecting, I can se the e-bays and printers, but I can’t se the content and I can’t connect to the printers.
I hope this information can help somebody to localize the problem.
Birger Koopmann
-
From an XPpro I sometimes can connect. If I succeed in connecting, I can se the e-bays and printers, but I can’t se the content and I can’t connect to the printers.
That gives a hint that it might be related to TCP MSS (maximum segment size). Someone might like doing some experiments with the iptables clamp-mss option.
-
I have been lurking here and following the PPTP posts and thought maybe I could add a bit of info that may be of interest to someone.
I have 4 SME Servers in production use at customers. All are ver 6.01 and 3 are setup to do PPTP VPN. The 4th is using a Windows server with PPTP access and an SME Server for email. Because there is a builtin PPTP client in WinXP Pro, I had been using a copy of that to connect to my customers system. Unfortunately, with 2 systems, I was having strange connection problems. The other 2 worked fine. I spent quite a bit of time trying to diagnose what was wrong and never could find a solution...until recently.
I normally can't stand even using WIndows for anything but since there wasn't an easy to use VPN client in any Linux distribution, I continued to deal with WinXP on a spare system for this task.
Recently Xandros released version 3.0 Deluxe and included an easy to use VPN client in the release. Much to my surprise the Xandros client not only worked perfectly with EVERY customers system, (including the MS PPTP server) but it actually "feels" faster and smoother. I have now dumped any trace of Windows from my systems and am happily using SME Server and Xandros for my needs.
Perhaps the issues some of you are experiencing have absolutely nothing to do with SME Server 6.01 and more to do with Windows.