Currently Being ModeratedJan 9, 2013 6:49 PM (in response to Ian L-F)
Curious if you ever found a solution to this. I am having (I think) the same problem. I am running the latester version of Server (2.2 - Mountain Lion)
The VPN is setup and I can log into it just fine. However, if I log into it with another device (iDevice or my MacBook Pro), whatever device I first logged into the VPN with gets knocked off in a few seconds to maybe a minute with the message "You were disconnected because the PPP server is not responding. Try reconnecting."
Happens every single time. I even tried creating separate user accounts for each device, thinking it was logging into the VPN / Server with the same account. But that is not the case. Creating separate accounts creates the same problem, no change.
I did find a reference to the problem in a post a while back and someone in response mentions that this is a limitation of the Server. No way that is possible. If there was no way to have multiple people/devices log into a server from a single IP source somewhere, VPN would be useless and never user. You have to be able to log multiple people into it.
Looking at the logs, I do see moments when the device gets bumped off. It usually includes messages with:
Unsupported Protocol 0x8057 received
rcvd [LCP TermReq id-0x3 "Peer not responding"]
LCP terminated by peer (Peer not responding)
fatal signal 6
no echo reply, start ppp_auxiliary_probe!
No response to 5 echo requests
Serial link appears to be disconnected.
Client with address = 10.0.1.xxx has hung up
Any suggestions as to what is going on or how to fix this?
Currently Being ModeratedJan 12, 2013 10:37 PM (in response to Ian L-F)
This is absolutely a facet of the VPN protocols. It does not expect multiple clients to be coming from the same IP address... ostensibly the server has no way of identifying user A from user B, so one or other connection will get dropped.
Most VPNs are not dealing with multiple clients from the same IP address. If you do have that then consider setting up a site-to-site VPN (where the entire remote LAN is connected to the VPN) rather than individual clients.
There are also numerous discussions on this, including various workarounds, including running multiple protocols (e.g. PPTP and L2TP at the same time, with one client on each), or upgrading the remote site's router to one that supports NAT-T which can help maintain multiple client VPN connections by tweaking the protocols.
Currently Being ModeratedJan 17, 2013 11:01 AM (in response to Camelot)
Ok, thanks. Still don't understand why having multiple logins with different accounts from the same network location (ie, a coffee shop where I am meeting with my team members, etc) should be a purposeful restriction, but at least I know its not a configuration issue. Guess if I need that, I will go around with a AirportExpress or Extreme and see if I can do it that way.
Currently Being ModeratedJan 17, 2013 3:54 PM (in response to kb8wfh)
Still don't understand why having multiple logins with different accounts from the same network location (ie, a coffee shop where I am meeting with my team members, etc) should be a purposeful restriction
As an overly simplified explanation, consider that all the traffic to/from the client is encrypted. As it passes through the NAT gateway (and gets translated to/from the private LAN from/to the shared public address) the traffic simply gets merged because it all looks the same and the NAT device cannot determine what traffic is from/to which host on the LAN - kind of like saying "Here's an encrypted packet from the VPN server... I wonder which client on the LAN it's supposed to go to...?" Since the router can't see into the payload it can't make that determination. Hence one or other client is going to drop.
If you don't control the router in the coffee shop, there's not much you can do about this since most solutions lay at the router level. If you have multiple public IP addresses at your server-side you might be able to control it there - setup multiple IP addresses for your VPN server and have each user connect to a different address. Since they're not connecting to the same server address there's no issue with sharing the connection.