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 sucks after Activation WAN-Balancing

Hi boys n girls,

the SSL VPN was well configured when there only was one wan-interface.

after i activated a secend uplink und configured traffic-shaping by connection the second interface works fine too.

but since then the logon via ssl doesn't work anymore correctly.

the initial login works, the vpn-pool-ip is assigned und the routes are set. but after a while the tunnel goes down and reconnection fails.

here's a copy of the log on the client:

---------------------------------
Fri Jun 05 12:00:52 2009 TAP-WIN32 device [Astaro] opened: \.\Global\{48EC37D6-AF9E-4994-80F7-FCB3D2AE6389}.tap
Fri Jun 05 12:00:52 2009 TAP-Win32 Driver Version 9.3 
Fri Jun 05 12:00:52 2009 TAP-Win32 MTU=1500
Fri Jun 05 12:00:52 2009 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.242.2.6/255.255.255.252 on interface {48EC37D6-AF9E-4994-80F7-FCB3D2AE6389} [DHCP-serv: 10.242.2.5, lease-time: 31536000]
Fri Jun 05 12:00:52 2009 Successful ARP Flush on interface [6] {48EC37D6-AF9E-4994-80F7-FCB3D2AE6389}
Fri Jun 05 12:00:57 2009 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
Fri Jun 05 12:00:57 2009 route ADD 10.242.2.1 MASK 255.255.255.255 10.242.2.5
Fri Jun 05 12:00:57 2009 Route addition via IPAPI succeeded [adaptive]
Fri Jun 05 12:00:57 2009 route ADD 192.168.10.0 MASK 255.255.255.0 10.242.2.5
Fri Jun 05 12:00:57 2009 Route addition via IPAPI succeeded [adaptive]
Fri Jun 05 12:00:57 2009 route ADD 93.93.251.128 MASK 255.255.255.240 10.242.2.5
Fri Jun 05 12:00:57 2009 Route addition via IPAPI succeeded [adaptive]
Fri Jun 05 12:00:57 2009 Initialization Sequence Completed
Fri Jun 05 12:01:33 2009 write TCPv4_CLIENT: Connection reset by peer (WSAECONNRESET) (code=10054)
Fri Jun 05 12:01:33 2009 Connection reset, restarting [-1]
Fri Jun 05 12:01:33 2009 TCP/UDP: Closing socket
Fri Jun 05 12:01:33 2009 SIGUSR1[soft,connection-reset] received, process restarting
Fri Jun 05 12:01:33 2009 Restart pause, 5 second(s)
Fri Jun 05 12:01:38 2009 Re-using SSL/TLS context
Fri Jun 05 12:01:38 2009 LZO compression initialized
Fri Jun 05 12:01:38 2009 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
Fri Jun 05 12:01:39 2009 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Jun 05 12:01:39 2009 Local Options hash (VER=V4): 'dfb47a97'
Fri Jun 05 12:01:39 2009 Expected Remote Options hash (VER=V4): '8edbeeaa'
Fri Jun 05 12:01:39 2009 Attempting to establish TCP connection with 93.93.251.142:20443
Fri Jun 05 12:02:00 2009 TCP/UDP: Closing socket
Fri Jun 05 12:02:00 2009 route DELETE 93.93.251.128 MASK 255.255.255.240 10.242.2.5
Fri Jun 05 12:02:00 2009 Route deletion via IPAPI succeeded [adaptive]
Fri Jun 05 12:02:00 2009 route DELETE 192.168.10.0 MASK 255.255.255.0 10.242.2.5
Fri Jun 05 12:02:00 2009 Route deletion via IPAPI succeeded [adaptive]
Fri Jun 05 12:02:00 2009 route DELETE 10.242.2.1 MASK 255.255.255.255 10.242.2.5
Fri Jun 05 12:02:00 2009 Route deletion via IPAPI succeeded [adaptive]
Fri Jun 05 12:02:00 2009 Closing TUN/TAP interface
Fri Jun 05 12:02:00 2009 SIGTERM[hard,init_instance] received, process exiting
-------------------------------------------------------------------

Thanks a lot for your help.


EDIT:

The initial configuration was made with the automativ packet rule.

the question is now: is the automatic packet rule adapted to the new inerfaces, coming u with the wan-balancing? might there be the problem?, but if so, why is the first connection possible???


This thread was automatically locked due to age.
  • Thanks a lot BAlfson.

    I tried now the following:
    - Open-VPN-Service automatic start
    - open vpn-config-file: added route-method exe, route-delay 5
    - deactivated the local firewall (client)
    - installaed Hotfix from KB953761

    an addition information:
    i don't think it's a problem with the client because i've 3 SSL-VPN-Connections to three different ASGs. the other two Connections work fine. it's only the one to my home office (the only with activated uplink balancing).

    so it seems to have sth. to do with the ASG-uplink-beahvior. either the automatic packet-filter-rules or the automatic d-nat-rules.

    as they were automatically set i don't know what exactly is set there.

    i'm wondering about these two entries in the local client-protocoll:
    Fri Jun 05 12:01:39 2009 Local Options hash (VER=V4): 'dfb47a97'
    Fri Jun 05 12:01:39 2009 Expected Remote Options hash (VER=V4): '8edbeeaa'

    what can cause the different hashes? is that the hash of the psk??

    any more ideas???

    thanks a lot in advice.

    kongafrites