FreeBSD 10; mpd5; PPTP session disconnects/timeouts

_martin

_martin

I'm using mpd5 as a PPTP server to bring samba shares to my client machines. On 9.2 this setup was stable without any hiccups. On FreeBSD 10 I hit this annoying behavior - session timeouts more-less randomly.
Consider my public IP as 192.0.2.1. My setup is the following :

I've loopback interface - lo251 - with 192.168.251.0/24 network. On this interface I've assigned 192.168.251.1 to be the IP of the samba server. Samba is listening only on this interface.

PF allows PPTP traffic, PPTP clients can use this server as a default gateway (hence the first line):
Code: 
nat pass on em0 inet from 192.168.251.0/24 to any -> 192.0.1.2
rdr pass on em0 inet proto tcp from any to 192.0.1.2 port = pptp -> 192.168.251.1 port 1723
rdr pass on em0 inet proto gre from any to 192.0.1.2 -> 192.168.251.1

mpd5 daemon is configured as follows (omitting admin user setup:

Code: 
default:
	load cloud

cloud:
	set ippool add cloud251 192.168.251.64 192.168.251.128

	# this connection is used for each peer connection
	create bundle template cloud_b
	set iface enable proxy-arp
	set iface enable tcpmssfix

	set ipcp yes vjcomp
	set ipcp ranges 192.168.251.2/24 ippool cloud251

	# MS point-to-point encryption
	set bundle enable compression
	set bundle crypt-reqd
	set ccp yes mppc
	set mppc yes e40
	set mppc yes e128
	set mppc yes stateless

	create link template cloud_link pptp
	set link action bundle cloud_b
	set link enable multilink
	set link no pap chap eap
	set link enable chap
	set link enable chap-msv2
	set link keep-alive 0 0
	set link mtu 1448

	# configure pptp
	set pptp self 192.168.251.1
	set enable always-ack
	set link enable incoming
#
Users on this network can access public shares. Daemons are of the following versions (the same before and after upgrade):

Code: 
# pkg info mpd5 samba36
mpd5-5.7
samba36-3.6.22
#
Everything is working as expected when client is not idle, i.e. traffic is passing through. Problem occurs when client is idle. Session timeouts randomly. Sometimes even matter of minute(s). Clients are still the same, clients from different location have the same problem.

EDIT: today my session got terminated even when I was pushing data through it. But still, nothing in the log.

In mpd5 log I see the only that call was terminated:

Code: 
Feb 16 18:43:04 host mpd: [cloud_b-1] IFACE: Up event
Feb 16 18:46:02 host mpd: [cloud_link-1] PPTP call terminated
Feb 16 18:46:02 host mpd: [cloud_link-1] Link: DOWN event
Feb 16 18:46:02 host mpd: [cloud_link-1] LCP: Close event
Feb 16 18:46:02 host mpd: [cloud_link-1] LCP: state change Opened --> Closing
Feb 16 18:46:02 host mpd: [cloud_link-1] Link: Leave bundle "cloud_b-1"

Did someone maybe hit the same behavior ?

UPDATE: Seems to be fixed in newer releases (verified in r264316).

UPDATE2: actually, it didn't solve it at all. It took longer for the issue to occur (2days), but now it's the same :/. Nightmare ..
 
Re: FreeBSD 10; mpd5 ; PPTP session disconnects/timeouts

Well, I tried to figure it out but without any luck. I did tcpdump on gre / pptp to see if I can find something causing these disconnects. Nada.
I modified the mpd5.conf to send keepalives on link:

Code: 
	set link keep-alive 5 40   # defaults
But that didn't help either.

I did reboot back to 9.2 and everything is working hunky-dory. No keepalives are even sent in original setup. These issues mean no 10.0 for me :(.

If anybody hits the same problem please share.
 
I tried to analyse the PPTP traffic on both sides of the connection. Test consisted of client connecting to a server, logging to a Samba share and staying idle. Prior to each test tcpdump()/wireshark was launched on respective node.

Every time session ended after certain time (time differed each time but was always less than 10 minutes). Connection started as expected, every second there was a live traffic (PPP/GRE) between these nodes. After a while client requested echo-reply 5 times in 1 minute interval (5 mins total). Each time it got a successful reply. After that server sent PSH and RST packet which ended the session.

In summary there's a live session, period of silence, 5 times echo and then PSH and RST which results in dropped connection. It doesn't matter if the client is active or stays idle.

I also ran tcpdump() on ng0 interface which was created once the PPTP session was opened. That live traffic was a Samba traffic, that stopped after a while. Tests showed that it doesn't matter if there is a live traffic or not, session does get cut either way. There was no traffic on ng0 interface indicating a problem when connection got closed.

Other connections (not PPTP related) don't have this problem. If the client has an idle SSH connection to this server it stays up without a problem.

As stated, the same PPTP configuration works ok on FreeBSD 9.2. I tried to post this issue on mailing list too, but I don't think I'll get any answer there. So I'm hoping if maybe somebody has any ideas how to proceed with the troubleshooting, please share.
 
I turned on verbose logging in mpd.conf with:
Code: 
	log +ALL -EVENTS -FRAME
and did another set of tests. Client just logged in and stayed idle. Traffic of the active PPTP session looked like:

Test #1:
Code: 
Apr 27 02:09:35 fbsd10 mpd: pptp0: recv EchoRequest
Apr 27 02:09:35 fbsd10 mpd:   id=0x6000000
Apr 27 02:09:35 fbsd10 mpd: pptp0: send EchoReply msg
Apr 27 02:09:35 fbsd10 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 02:09:35 fbsd10 mpd:   id=0x6000000 result=1 err=0 ignore=0

Apr 27 02:10:35 fbsd10 mpd: pptp0: send EchoRequest msg
Apr 27 02:10:35 fbsd10 mpd:   len=16 msgType=1 magic=0x1a2b3c4d type=5
Apr 27 02:10:35 fbsd10 mpd:   id=1
Apr 27 02:10:35 fbsd10 mpd: pptp0: recv EchoRequest
Apr 27 02:10:35 fbsd10 mpd:   id=0x7000000
Apr 27 02:10:35 fbsd10 mpd: pptp0: send EchoReply msg
Apr 27 02:10:35 fbsd10 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 02:10:35 fbsd10 mpd:   id=0x7000000 result=1 err=0 ignore=0
Apr 27 02:10:35 fbsd10 mpd: pptp0: recv EchoReply
Apr 27 02:10:35 fbsd10 mpd:   id=1 result=1 err=0 ignore=0

Apr 27 02:11:35 fbsd10 mpd: pptp0: send EchoRequest msg
Apr 27 02:11:35 fbsd10 mpd:   len=16 msgType=1 magic=0x1a2b3c4d type=5
Apr 27 02:11:35 fbsd10 mpd:   id=2
Apr 27 02:11:35 fbsd10 mpd: pptp0: read: Connection reset by peer
Apr 27 02:11:35 fbsd10 mpd: pptp0: ctrl state ESTABLISHED --> DYING
Apr 27 02:11:35 fbsd10 mpd: pptp0: killing connection with <CLIENT_IP> 49595
Apr 27 02:11:35 fbsd10 mpd: pptp0-0: killing channel
Apr 27 02:11:35 fbsd10 mpd: [cloud_link-1] PPTP call terminated
Apr 27 02:11:35 fbsd10 mpd: [cloud_link-1] device: DOWN event
Test #2:
Code: 
Apr 27 02:28:16 fbsd10 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 02:28:16 fbsd10 mpd:   id=0x5000000 result=1 err=0 ignore=0

Apr 27 02:29:16 fbsd10 mpd: pptp0: recv EchoRequest
Apr 27 02:29:16 fbsd10 mpd:   id=0x6000000
Apr 27 02:29:16 fbsd10 mpd: pptp0: send EchoReply msg
Apr 27 02:29:16 fbsd10 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 02:29:16 fbsd10 mpd:   id=0x6000000 result=1 err=0 ignore=0

Apr 27 02:30:16 fbsd10 mpd: pptp0: send EchoRequest msg
Apr 27 02:30:16 fbsd10 mpd:   len=16 msgType=1 magic=0x1a2b3c4d type=5
Apr 27 02:30:16 fbsd10 mpd:   id=1
Apr 27 02:30:16 fbsd10 mpd: pptp0: read: Connection reset by peer
Apr 27 02:30:16 fbsd10 mpd: pptp0: ctrl state ESTABLISHED --> DYING
Apr 27 02:30:16 fbsd10 mpd: pptp0: killing connection with <CLIENT_IP> 49732

In test #2 connection went down sooner. It seems that the "type 5" message has something to do with it. I checked the RFC 1661 for PPP specification but I found no information on what that type might be.
I looked at mpd5 sources (v5.7); it seems it's defined in pptp_ctrl.h as PPTP_EchoRequest (type 6 is PPTP_EchoReply).

I rebooted back to 9.2 to check the behavior there. I saw only type 6 messages:

Code: 
Apr 27 16:40:33 fbsd9 mpd: pptp0: recv EchoRequest
Apr 27 16:40:33 fbsd9 mpd:   id=0x23000000
Apr 27 16:40:33 fbsd9 mpd: pptp0: send EchoReply msg
Apr 27 16:40:33 fbsd9 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 16:40:33 fbsd9 mpd:   id=0x23000000 result=1 err=0 ignore=0
Apr 27 16:41:33 fbsd9 mpd: pptp0: recv EchoRequest
Apr 27 16:41:33 fbsd9 mpd:   id=0x24000000
Apr 27 16:41:33 fbsd9 mpd: pptp0: send EchoReply msg
Apr 27 16:41:33 fbsd9 mpd:   len=20 msgType=1 magic=0x1a2b3c4d type=6
Apr 27 16:41:33 fbsd9 mpd:   id=0x24000000 result=1 err=0 ignore=0
with no type 5 messages at all. Session stays up without problem.

But logic to keep the link up is in the mpd5 which is the same version on 9.2 and 10.0.

Question is: what is the reason of those type 5 messages then ? Or is the focus on those messages relevant ?
 
To a certain extent, I am also interested in this issue, since I plan to update my VPN server from 9.2 to 10.0 in the foreseeable future, and probably will run into the same issue. However, I cannot be of big help with that, other than to point you to the MPD-Forum on SourceForge. I guess, the developers of MPD might have a better understanding about what is going on here.
 
@obsigna Thanks for pointing me to those forums. It didn't cross my mind to check it on sourceforge.

If you do update please let me know if you're experiencing the same issue. This behavior makes mpd5/PPTP absolutely worthless on 10.0.
 
Last edited by a moderator:
As nobody replied on FreeBSD mailing lists I'm giving up there to find any hints.

I tried several tests scenarios to find at least the location where the issue is originating from. As mpd version is the same on both FreeBSD versions I'm leaning towards the issue there (BSD), not on mpd.

After many tests scenarios I found something interesting. It seems my setup is working correctly when mpd is bound to egress interface without PF. It works even if PF is used but no redirect is used (mpd is listening again on public interface). I can't say I know what to do next, but is seems PF is the troublemaker here.
 
So, I'll give here an update to my near-monologue :-).

@obsigna Your advice was priceless. Dmitry, one of the mpd programmer did reply to my thread and gave me some ideas how to proceed. Even more, I was able to share this with one of the FreeBSD's programmers.

Currently PF is a suspect in this issue. Tests showed rdr rules might have something to do with this. In my scenario I bind mpd to a loopback interface and redirect the traffic here from outside. This has an advantage of moving mpd to jail, etc. and provide sort of network isolation.

I found a workaround which suits me best in this scenario: bind mpd to an egress interface (use nat if needed). In this setup rdr rules are not needed; issue does not occur.
 
Last edited by a moderator:
Well, good to hear that you found a satisfying solution, and thank you for letting us know.

Now, I have less fear to upgrade my 9.2 machine to 10. I am running my VPN service behind ipfw(8) and its in-kernel NAT, and mpd5(8) is bound to the LAN-IP of the server, therefore, when I connect via VPN from the outside, I have access also to other machines of the internal network.
 
You must log in or register to reply here.
Back
Top