Cisco VPN client disconnects after a minute

Home Page Forums Network Management ZeroShell Cisco VPN client disconnects after a minute

This topic contains 12 replies, has 0 voices, and was last updated by  mlapeyre 4 years, 6 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #42164

    mlapeyre
    Member

    Hi all,

    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?

    #49491

    Marcelo
    Member

    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!

    #49492

    e_60
    Member

    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.

    #49493

    mlapeyre
    Member

    Marcelo:
    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

    e_60:
    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 friend

    #49494

    ppalias
    Member

    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.

    #49495

    mlapeyre
    Member

    ppalias:

    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?

    Fulvio:

    Do you have any thoughts in mind about modifying the authenticator behavior in order to cope this scenario?

    #49496

    ppalias
    Member

    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.

    #49497

    mlapeyre
    Member

    ppalias:

    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.

    #49498

    ppalias
    Member

    Yes I have understood what your problem is.

    #49499

    e_60
    Member

    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.

    #49500

    ppalias
    Member

    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.

    #49501

    atheling
    Member

    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.

    #49502

    kiall
    Member

    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 luck

    #49503

    rafaybutt
    Member

    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

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.