Topic: 5.6SME and VPN PPTP Call id issues - bug found and resolutio

[Vince Levalois]

When connecting via PPTP VPN to an SME v5.6 we've found issues related to GRE (Protocol 47) errors.  This was reported to Mitel 3 weeks ago and since then we've been trying to reproduce the problem with an XP Workstation (on which the problems have been consistent).  Whether from a NAT'ed remote station, from a dialup or public IP, the problem was the same.

Analysis of simultaneous tcpdumps from the SME Server and the XP machine revealed little since we could not reproduce the problem.... until this morning

Constantly pinging the SME server on the local side, then stopping and initiating a browser session of the Server Manager was enough to cause a GRE error in the messages log on the SME and halt ALL activity on the PPTP connection to the point of disconnection if degraded enough.

The close analysis found that the XP machine was giving out a consistent Call ID set to 0 on all packets.  The SME was set to Call ID 16384.  When the GRE error occurs, the XP shows sending 0 but the SME is receiving 16384... Coincidence?  We don't think so.

So, the solution is seems is to roll the PPTP RPM package back one level to see if the problem dissapears.  This would expose the culprit being the PPTP in the RPM and the balance of the 5.6 system can continue working as is

I'll update this post tomorrow after testing.

Vince L.

[Charlie Brady]

Vince Levalois wrote:

> So, the solution is seems is to roll the PPTP RPM package
> back one level to see if the problem dissapears.  This would
> expose the culprit being the PPTP in the RPM and the balance
> of the 5.6 system can continue working as is

Vince, I now suspect that the kernel modules which do NAT and connection tracking for PPTP, to support outbound connections, are the most likely cause. The first thing I'd suggest is that you unload the modules, by doing:

/sbin/rmmod ip_nat_pptp
/sbin/rmmod ip_conntrack_pptp

and then try a remote connection. You'll need to make sure that you don't have any outbound connections before you will be able to unload the modules.

Alternatively you could temporarily delete the module load lines from /etc/rc.d/init.d/masq and then reboot.

If this works we can make that change semi-permanent, and that'll solve your problem, but it doesn't help those who want to masquerade outbound connections

Regards

Charlie

[Vince Levalois]

We went to a prior version of pptp and no change...

It's up to you now Charlie!

Vince Levalois

[steve]

If it helps, I get the same problem on Win 98 2nd Ed. and on Windows 2000 Pro.
Also, when I could not pptp into my server across the Internet, I tried to connect to some other services that were running and could not access them across the Internet either.
I know the firewall has changed, could it have to do with the firewall or packet filtering??

steve

[Steve Landers]

Charlie Brady wrote:

> Vince, I now suspect that the kernel modules which do NAT and
> connection tracking for PPTP, to support outbound
> connections, are the most likely cause. The first thing I'd
> suggest is that you unload the modules, by doing:

...

I suspect your are right ... I can't see anything in the iptables rules that would affect the masquerading.

> If this works we can make that change semi-permanent, and
> that'll solve your problem, but it doesn't help those who
> want to masquerade outbound connections

That would be truly unfortunate

Steve

---

Steve Landers                     Scripting Design Studio
Digital Smarties                  steve@digital-smarties.com
Perth, Western Australia          DigitalSmarties.com

[Charlie Brady]

steve wrote:

> I know the firewall has changed, could it have to do with the
> firewall or packet filtering??

Possibly. I tried to replicate the problem this afternoon without success. But I am running a development version of the firewall code. You're welcome to try that. You can get it from ftp://ftp.e-smith.org/pub/e-smith/contrib/CharlieBrady/5.6-PPTP/.
You'll also find there an RPM of the pptp nat/connection tracking kernel modules which has debugging code compiled in.

To activate, upgrade the RPMs, then do:

/sbin/e-smith/db config setprop masq Logging all
/sbin/e-smith/signal-event post-upgrade
/sbin/e-smith/signal-event reboot

The modules do quite verbose logging. If the packet filter changes help you, and you don't want the logging, you might want to roll back to the production version of the rpm:

mount /mnt/cdrom
rpm -Uhv --oldpackage /mnt/cdrom/e-smith/RPMS/\
pptp-conntrack-nat-1.0.0-3es.i686.rpm
umount /mnt/cdrom

and then you'll need to unload the ip_nat_pptp and ip_conntrack_pptp modules. The modules will need to be idle for you to unload them - it might be easier just to reboot.

Regards

Charlie

[Steve Landers]

Charlie Brady wrote:

> Possibly. I tried to replicate the problem this afternoon
> without success. But I am running a development version of
> the firewall code. You're welcome to try that.
...
> You'll also find there an RPM of the pptp nat/connection
> tracking kernel modules which has debugging code compiled in.

I first installed the e-smith-packetfilter-1.13.0-07.noarch.rpm RPM, ran post-upgrade and rebooted but no change.

Then did the same with pptp-conntrack-nat-1.0.0-4es.i686.rpm and had success. Can now have an outoing pptp connection through the SME 5.6 box.

I haven't tried regressing and just installing the second RPM - I'm just happy it is working Let me know if there's anything else I can do to help track this down.

Cheers

Steve

[Steve Landers]

I wrote:
> Then did the same with pptp-conntrack-nat-1.0.0-4es.i686.rpm
> and had success. Can now have an outoing pptp connection
> through the SME 5.6 box.

Not quite ....

The outgoing connection stayed up for around 4 minutes, then disconnected and couldn't be re-established until I rebooted the server.

So, I've turned on tracing.  The results of tracing an attempted connection are at http://www.digital-smarties.com/pub/pptp-trace

HTH

Steve

[John Morrissey]

I'm having problems with INBOUND connection on 5.6 as wellas outgoing.  

Since the upgrade to 5.6 inbound PPTP has been difficult to establish and once established its been flakey at best.  

In order to establish a connection in either direction I have to disable the auto negotiation on the W2K client and fix the setting at PPTP.

I wont be able to try Charlies beta rpms until Tuesday as the box is at another site.



.

[Charlie Brady]

Steve Landers wrote:

> Let me know if there's
> anything else I can do to help track this down.

Steve, if you could run three simultaneous tcpdumps, one on your client machine, and one on the internal and one on the external interface of your gateway, then send the three files, together with the relevant section of /var/log/messages, and a description of exactly what you were trying to do, and what you observed, to bugs@e-smith.com, then that would be a great help.

When you run tcpdump, please use "-s 0" to capture full packets, "-w xxx" to write to a file, and "-i ethX" to select the interface.

Thanks

Charlie

[Vince Levalois]

The great support team at Mitel has band-aided this situation successfully by removing (remming)

/sbin/rmmod ip_nat_pptp
/sbin/rmmod ip_conntrack_pptp

from the loadup script (masq).  Trying to unload the services simply crashed the server likely because of some dependency.

Once this was accomplished the connections are smooth as silk.  As stated though, no outbound masquerading of pptp connections.

Vince Levalois

[Brian Mills]

Could you give a brief instruction how to do this for a running esmith 5.6

[Brian Mills]

pico /etc/rc.d/init.d/masq

add the lines

/sbin/rmmod ip_nat_pptp
/sbin/rmmod ip_conntrack_pptp

to be the first actual commands in the file

save
reboot


Millsey

[Charlie Brady]

Brian Mills wrote:
>
> pico /etc/rc.d/init.d/masq
>
> add the lines
>
> /sbin/rmmod ip_nat_pptp
> /sbin/rmmod ip_conntrack_pptp
>
> to be the first actual commands in the file
>
> save
> reboot

I doubt that will help. That will try to rmmod some modules which aren't loaded, and then will load those very modules. I recommend instead commenting out the "/sbin/modprobe ip_nat_pptp" and "/sbin/modprobe ip_conntrack_pptp" lines, then reboot.

And remember that this file is templated, so you should create a custom template fragment to prevent the loss of your change on reconfiguration.

Charlie

[Brian Mills]

OMG what a pratt!

I could not find the existence of these lines in the masq file but I found them as soon as you replied! I have now commented out the lines and will try connecting later, thanks!

I have no idea how to set this up as a template fragment, could you give me a little info on how to do this?

Millsey