January 25, 2010 at 11:40 am #42164
I’am using the captive portal feature of Zeroshell and all work ok, but when a user tries to connect to a VPN server using a Cisco VPN client ( with L2TP/IPSec ), the connection disconnects after a minute or so.
I think is something related to the authenticator window, because after that time it losses connection with Zeroshell and can’t renew and then Zeroshell ends the connection.
This behavior is just with the Cisco VPN client, but with the Windows Xp built-in vpn client ( L2TP/IPSec ) all works flawlessly.
Has anyone some experience with a L2TP/IPSec vpn client through Zeroshell?January 25, 2010 at 11:46 am #49491
Not sure, but sounds like you may be experiencing an inactivity disconnection. Chances are your Windows client is using a keepalive ping or something (the reason it doesn’t disconnect).
Try starting a ping through the VPN interface (from the client to te server) as soon as you connect and check if the problem persists.
Good luck!January 26, 2010 at 7:42 am #49492
You can do split-tunnel with your cisco gear so your machine continues to have access to the local zeroshell while connected to your asa or whichever.February 2, 2010 at 8:56 pm #49493
Pinging through VPN tunnel works ok; the reason why the connection is broken relates to the fact that all communication between the authenticator and Zeroshell is sent via the tunnel ( not to the gateway itself ), and after a predefined timeout, Zeroshell thinks the client disconnected from the session, and close the connection actually.
Thanks for your reply
I have found that for Cisco VPN Client, in order to do split-tunneling, 2 requeriments must be fulfilled:
1. Check “Allow Local LAN access” at the client
2. VPN concentrator must be configured to allow local LAN access to clients, and create a list of allowed networks to be accessed locally at the client site. This list is downloaded by the client after the tunnel was established.
In my situation, Zeroshell is installed at a hotel, so usually people using the client software has no administrators rights to change the configuration, and wouldn’t take the time to call to IT support in order to ask them to include his local network in the allowed networks list ( even worse, probably the net admin wouldnÂ´t want to do that )
With the Microsoft VPN Client, access to the local network is allowed by default, so the authenticator can communicate with Zeroshell without problem.
Thanks for your help my friendFebruary 3, 2010 at 7:46 am #49494
Sounds like a route conflict problem to me… After the tunnel has been established there should be a route in the routing table that allows the client to communicate to the server without tunneling the traffic. Check if this route exists.February 3, 2010 at 2:05 pm #49495
For sure is a route issue, and could be changed from the command line, but the point here is that most of our customers couldn’t (because of lack of administrative privileges) and even wouldn`t want to do that job.
Routes are modified by the VPN client when connects to the concentrator.
I am looking for a solution where the customer needs no additional configuration to be done by him and/or by the net admin at the concentrator’s site.
Imagine my frustration when a customer told me that he had to go to a Starbucks nearby in order to be able to connect to his office network because at the hotel was impossible to do it.
I am sure that many of us are using Zeroshell at a hotel-like enviroment, so my question is:
haven’t you challenge this problem with your customers using Cisco (or maybe another) VPN Client?
Do you have any thoughts in mind about modifying the authenticator behavior in order to cope this scenario?February 3, 2010 at 7:18 pm #49496
I will try the same with my cisco vpn client at a remote site and get back to you. However my ZS is not working with captive portal.February 6, 2010 at 6:09 pm #49497
I think that maybe there are some confusion regarding my scenario.
I have ZS installed in a hotel with the captive portal option enabled, and I want that any customer with a Cisco VPN client can connect to his office network from inside the hotel LAN.
So, if you can help me with some test in a similar scenario, I would be very grateful.February 7, 2010 at 6:24 pm #49498
Yes I have understood what your problem is.February 8, 2010 at 6:07 pm #49499
my guess from what I have read so far is that you are giving your hotel users private ip’s from the same range as his corporate network.February 10, 2010 at 9:53 am #49500
I tried it at my home, cisco vpn worked fine for 3 minutes, then I disconnected it cause I had to leave, but I don’t think there would be a problem if I left it for more time. I don’t have a captive portal, so I would suggest you try without it to narrow down the problem’s list.February 10, 2010 at 6:53 pm #49501
For what its worth, I’ve been connected from home to work for hours on end through the Zeroshell box using the Cisco AnyConnect VPN client.
Not sure how the older Cisco VPN client would work as I no longer have an end point to try it with. And the Cisco AnyConnect VPN client does not play nice with other VPN software (I have to manually unload a TUN driver it installs at boot time to allow OpenVPN to run on that same machine).
But I’m not running the captive portal feature of Zeroshell, so I don’t know if that would get in the way or not.March 19, 2010 at 12:47 am #49502
I believe mlapeyre is correct that people are not understanding his issue 🙂
Cisco VPN clients work perfectly with captive portal turned off.
The issue is that the captive portal authenticator, once the VPN is connected, cannot communicate with ZS.
This issue is caused by the Cisco VPN client restricting access to the local network – ZS then disconnects the user after a few minutes because the authenticator hasn’t called home.
There is no way around this other than having the user change a setting in the cisco VPN client AND their network admin allowing them to make that change.
Your only true solution is to turn off captive portal.
BUT – You can mask this problem by increasing the Authenticator Validity as high as possible, that way, the disconnects are not every minute, but every few hours – Enough that most people wont notice!
Its also possible (I dont know the specific protocols/ports used by Cisco VPN … so i may be wrong) that you can allow VPN access as “Free Authorized”. This should allow the VPN to stay connected…
Good luckOctober 10, 2014 at 5:59 am #49503
I am using Hotspot Shield.I have used many other software but fund this one more comfortable and reliable works perfect not only on my PC but also on smartphone.i used for many time but it never disconnects. I downloaded it form the link below.So check out the link and try.
Mac & Windows: http://bit.ly/1qZZNva
You must be logged in to reply to this topic.