Topic: Packet capture to isolate LCP timeout on VPN connection attempt

[mophilly]

I want to log PPTP traffic until I encounter one or more failed vpn connection attempts; see the Background Story. This morning I spent a couple of hours reading the tcpdump man page and related how-to pages on the web. tcpdump is truly a complex utility offering many options that I do not understand. I am learning but could use a bit of help.

Can anyone offer a suggestion or example of using tcpdump capture only packets those relating to PPTP?

TIA.

The Background Story:

I am slouching my way to greater understanding about VPN connections. The basic problem of my ignorance continues to be an obstacle.

The setup: a Mac OS X, v10.5.8, (OSX) client running behind SME Server/Gateway (SME). SME is set to allow incoming VPN and the OSX needs to connect to external VPN's frequently. The outbound connection attempts succeed about 1 in 10 times. The inbound connections by remote users are successful 1 out 20 attempts. Occasionally, clients seem to get "stuck", lose connection and cannot re-connect. A client reboot clears that problem.

Back in April, Charlie Brady was kind enough to offer this answer to my question "What might be causing outbound VPN connects to fail?".

There are quiet a few possible reasons. I think the most likely one is that a GRE packet from the VPN server is arriving SME WAN interface before your VPN client has sent one through the SME server. Because you have inbound VPN clients, the iptables firewall is configured to allow inbound GRE. If your MAC client is setting up a PPTP connection to an external server, the external server and the MAC client will start to send each other GRE packets. The GRE packets contain LCP negotiation traffic. If a GRE packet from MAC client to remote PPTP server is the first to pass through SME server, all is good. When the server to MAC client packet arrives, it will be forwarded to the MAC client. If the remote server to MAC client packet arrives first, SME server will not know to forward it to the MAC client, so will try to process it. Because there is no process waiting for that packet, it will be rejected - an ICMP packet will be sent back to the remote VPN server.

To test this theory, disable inbound PPTP, and try again. Or just do packet capture and see exactly what is happening.

Disabling the inbound PPTP traffic did allow the outbound connections to succeed with two different external servers. BTW, one was another SME install and one was some other brand of vpn gateway.

So looking into the ippp log on SME I don't see anything particularly interesting.

Here is a snippet of the Mac OS X 10.5.8 client's ppp.log
Fri Nov  6 06:42:43 2009 : PPTP connecting to server 'xxx.xxx.xxx.xxx' (xxx.xxx.xxx.xxx)...
Fri Nov  6 06:42:44 2009 : PPTP connection established.
Fri Nov  6 06:42:44 2009 : Using interface ppp0
Fri Nov  6 06:42:44 2009 : Connect: ppp0 <--> socket[34:17]
Fri Nov  6 06:43:14 2009 : LCP: timeout sending Config-Requests
Fri Nov  6 06:43:14 2009 : Connection terminated.
Fri Nov  6 06:43:14 2009 : PPTP disconnecting...
Fri Nov  6 06:43:14 2009 : PPTP disconnected

[axessit]

I have this exact problem with Windose clients behind SME. I use Vista client to connect to remote VPN connection terminated on Windose server all OK. Then try VPN to remote SME server and it fails. Go to WinXP machine on my local network and VPN out no worries to remote Windose server. If I disable the inbound PPTP  on my local SME, then all works OK from my Vista machine again. So I just keep local PPTP=0 unless I know I'm going away for a while thne enable one session.

Never got to the bottom of it, just live with it. At one stage thought it was a remote SME problem and upgraded the remote server SME from SME 7.2 to 7.4 which seemed to fix things for a while or so I thought.

[mophilly]

Thanks for the reply.

In my case, the SME server in question supports five remote employees and five "inside" users. Shutting down VPN access isn't a viable option. Of course, setting up a separate vpn gateway is an option, which may be the best solution in the short run.

Beyond that, I find this problem interesting. My intention is to log the various activities until I can isolate two or three cases where the failure occurs, and use that information to build a reproducible test case. The test case being something that might be useful to the SME team or perhaps the developers of the vpn modules themselves.

So I continue to study the manuals, slowing gathering enough detail to "get it", and encourage anyone with experience using tcpdump or something Wireshark to make a suggestion, offer a link, etc..

[johnp]

You may want to look at the openvpn-bridge contrib. Since I began using it, I haven't had any problems like above.

[mophilly]

You may want to look at the openvpn-bridge contrib. Since I began using it, I haven't had any problems like above.

Thanks, didn't realize there was something like that, although I should have guessed there would be.

BTW, I assume you mean this link: http://wiki.contribs.org/OpenVPN_Bridge

[johnp]

You are correct

[CharlieBrady]

Can anyone offer a suggestion or example of using tcpdump capture only packets those relating to PPTP?

Try:

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

Note, I think there is an error there. It says:

tcpdump -i eth0 -w my.tcpdump -s 0 tcp port 1723 or proto 47

but I think you need:

tcpdump -i eth0 -w my.tcpdump -s 0 'tcp port 1723 or proto 47'

and in fact I think you also need to capture icmp, so:

tcpdump -i eth0 -w my.tcpdump -s 0 'tcp port 1723 or proto 47 or icmp'

[mophilly]

Thanks, Charlie. I will give that a try.