Topic: PPTP connections have been unreliable since E-Smith 5.5

[Anonymous]

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?

[guest22]

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

[smeghead]

.. 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

[raem]

> 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.

[cc_skavenger]

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

[pwalter]

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.

[raem]

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 ?

[pwalter]

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

[raem]

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.

[pwalter]

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

[percheron]

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

[pwalter]

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

[ryan]

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

[pwalter]

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

[ryan]

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