This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN connects, PING works, but sometimes no traffic (timeout)

We have an ASG220 running firmware version 7.405 and we are experiencing problems when connecting notebooks of our external sales representatives to our LAN through a SSL VPN connection. The goal is to sync Outlook with the corresponding Exchange Server 2007 mailbox and use fileserver shares.

Right from the beginning we had the problem, that the SSL VPN was connecting properly (green light), a command level PING to the server was running successfully but the actual sync within Outlook did not work (timeout) and an authentication screen appeared. After disconnecting the SSL VPN and reconnecting again, it may happen that it works directly or sometimes after a couple of reconnects and eventually after restarting the computer. This behaviour occurs on several different notebooks and is causing lots of frustration.

The logfiles and live logs just contain normal information.

We are running Windows XP Pro SP3 on the notebooks and have downloaded and installed the latest client from the user portal (ASG 7.405). The Installation was done as Administrator. The normal user has no administrative rights, but was put into the local Network Config. Operators group and the Astaro's installation directory has been set to write acess for normal users.

Network Security -> Packet filter:
- Source.....: Group of Static Users
- Service....: Any
- Destination: Network group of Hosts

Remote Access -> SSL:
- Global: ON
- Specific Users with access to LAN.
- NO automatic packet filter rules
- Protocol: TCP
- Port: 443
- Pool network: VPN Pool (SSL)

Network Security -> NAT:
- Masquerading rule for VPN Pool (SSL)

We need to get this properly working a.s.a.p.

Thanks for any suggestions that may help.

Waiting for answers... Manfred


This thread was automatically locked due to age.
  • Check that the SSL VPN Adapter is first in the sequence of network adapters in each notebook: How to change the binding order of network adapters in Windows XP and in Windows 2000.

    Also, what is 'Group of Static Users'?  The User Guide says explicitly that a static IP assigned to a local User in the Astaro does not work with SSL.

    Cheers - Bob
  • Hi Bob,

    I've checked the proper sequence on six notebooks. The sequence was always first, which should allow for normal traffic right away. On some of these notebooks the SSL VPN mostly works just fine, on others there are connection problems more often.

    The 'Group of Static Users' is the User Group containing all users created locally on the Astaro itself for VPN authentication. See the attached screenshots!

    I have no idea, what to do in order to fix this problem. Do you think the new VPN from ASG version 7.500 could help?

    Also, I did not yet update to 7.500 when I read about problems with it. What is the recommendation for the upgrade? Wait until 7.501 is available or update immediately?

    Thanks,
    Manfred
  • I'm a little confused by the way you have this configured.  I don't understand what the packet filter rule is supposed to accomplish.

    As I said above, you cannot use the fixed IP in the Local User definition in the SSL VPN.

    Why not just list the users on the 'Global' tab of SSL, check 'Automatic packet filter rules' and in 'Local networks', list the subnets and hosts these folks are allowed to access?

    Cheers - Bob
    PS None of my clients will upgrade to 7.5 until I've run 7.501 for a week or so in production in our office.
  • Manfred- are the clients having problems with getting DNS responses over the VPN?  There is an IPS rule issue in 7.500, and in all versions there are some odd DNS behaviors in some Windows systems.
  • Re. Bob>>

    Well, we configured SSL VPN this way, because we want different people (2 User Groups) have access to different servers. Therefore, we have the following configuration in details:

    Remote Access --> SSL:
    ------------------------
    *** Global ***
    Users and Groups:
    - admin
    - VPN_SSL User ADM (User Group)
    - VPN_SSL User HV  (User Group)

    Local Networks:
    - Internal W1 (172.21.0.0/16)
    - Internal W2 (172.22.0.0/16)

    Automatic packet filter rules:
    - NO

    *** Settings ***
    Server settings:
    - Protocol: TCP
    - Port: 443
    - Override hostname: {subdomain}

    Virtual IP pool:
    - Pool network: VPN Pool (SSL)

    Duplicate CN:
    - YES

    *** Advanced ***
    Cryprographic algorithm:
    - AES-192-CBC
    - MD5
    - 2048 bit
    - Local X509 Cert
    - 28800

    Compression setting:
    - ON

    Debug Settings:
    - OFF

    Network Security --> Packet Filter:
    ----------------------------------
    *** Rules ***
    VPN_SSL User ADM:
    - Source.....: VPN_SSL User ADM (User Group)
    - Service....: Any
    - Destination: VPN Adresspool ADM (Network group 1, List of LAN Hosts)

    VPN_SSL User HV:
    - Source.....: VPN_SSL User HV (User Group)
    - Service....: Any
    - Destination: VPN Adresspool HV (Network group 2, List of LAN Hosts)

    Network Security --> NAT:
    --------------------------
    *** Masquerading ***
    Network: VPN Pool (SSL)
    Interface: Internal

    Bob, does this clarify things?

    ___________________________________________________________

    Re. Jack Daniel>>

    I don't know if there is a DNS issue here. The only thing I can say is, when I try to ping a server by its name (DNS and WINS) then there is always immediately a successful answer, although Outlook 2003 not always wants to synchronize right away.
  • Your masq rule should not be necessary unless your intent is to allow VPN users to access the internet, in which case, you should list the External interface instead.

    If the 'Override hostname' is the same as the hostname of the Astaro, that field can be left blank.

    I suspect that the problem lies in using the addresses of AD-authenticated users.  What do you see in the PF log when access is not successful?
  • We need the masq rule because otherwise I think the routing doesn't work proberly back and forth. I don't really remember ... The VPN Users do not need to access the internet. Maybe I'll test to deactivate the masg rule in the evening to see what happens. But that should not cause the hanging VPN traffic.

    Our 'Override hostname' is different from the hostname of the Astaro. The Astaro's hostname is within the local domain, whereas the Override hostname is a subdomain of our public domain.

    The PF live log just contains regular 'green' logfile entries for normal operation. Nothing else for that specific client.

    BTW, when there is no VPN traffic, it normally helps to exit the SSL VPN Client and restart it again through the startmenu. Then, normally everything works right away. Might there be some kind of timing problems?
  • That "timing" issue is why I guessed that this was related to AD-Authentication.  On the 'Advanced' tab of 'Users >> Authentication', do you have prefetch configured?  Do you have the box checked for SSL VPN in 'Automatic creation of users...'?

    Also, please check the Intrusion Protection log.

    Cheers - Bob
  • On the 'Advanced' tab of 'Users >> Authentication', there is no such prefetch option. I guess, you meant the 'Active Directory' tab of the 'Users >> Authentication' section. Well NO, we do not have prefetch configured, since we are authenticating against local Astaro users for SSL VPN. We will be activating the Active Directory integration soon, in order to provide access to the User Portal for every user's SMTP mail quarantine.

    This covers your second question: No, we do not yet have the box checked for SSL VPN in 'Automatic creation of users...'. Is it recommended, to use Active Directory for VPN authentication rahter than authentication against locally created users?

    It seems as if there is nothing in the Intrusion Protection log.

    See the appended screenshots for details!

    Bye, Manfred
  • On the 'Advanced' tab of 'Users >> Authentication', there is no such prefetch option..

    Sorry, I just reread the beginning of the thread and realized you're not on 7.5 yet!

    Mannfred, this is strange, and especially diffcult because it's not all of the units and you can get them to sync after reconnects and restarts.  I don't understand how DNS would be the problem, but Jack Daniels knows more about this than we do - when you ping by hostname instead of IP, do you still get a response?  Also, is there any difference in routing tables on the PC when syncing works compared to when it doesn't?

    I expect that the 7.501 Up2Date will be released in the next day or so.  It has worked well in our small office, so we'll tell our clients to go ahead and do the Up2Date to7.500 and 7.501.  Maybe the new client in 7.5 will solve your problem.

    Perplexed - Bob