Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 11341 views
  • Users 0 members are here
Options
Suggested
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 disconnects when transferring large amounts of data (OpenVPN bug)

phemmer
We are currently experiencing an issue with the SSL VPN where when you transfer large amounts of data through the tunnel, the VPN terminates.

Client log: 
2013-09-18 12:07:01 daemon/err(3) nm-openvpn[31170]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #7597 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

2013-09-18 12:07:01 daemon/err(3) nm-openvpn[31170]: Fatal decryption error (process_incoming_link), restarting

2013-09-18 12:07:01 daemon/notice(5) nm-openvpn[31170]: SIGUSR1[soft,decryption-error] received, process restarting


Server log: 

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Connection reset by peer (code=104)

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Broken pipe (code=32)

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Broken pipe (code=32)

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Broken pipe (code=32)

...

...

...

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Broken pipe (code=32)

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 write TCPv4_SERVER: Broken pipe (code=32)

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 Connection reset, restarting [0]

2013:09:18-16:07:01 gate-a openvpn[3790]: phemmer/1.2.3.4:9152 SIGUSR1[soft,connection-reset] received, client-instance restarting

2013:09:18-16:07:01 gate-a openvpn[3790]: id="2202" severity="info" sys="SecureNet" sub="vpn" event="Connection terminated" username="phemmer" variant="ssl" srcip="1.2.3.4" virtual_ip="10.230.134.70"

2013:09:18-16:07:01 gate-a openvpn[3790]: PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_CLIENT_DISCONNECT status=0



This issue is being caused by a bug in OpenVPN 2.3.0 (the version the UTM uses), and has been resolved upstream. Details here: https://community.openvpn.net/openvpn/ticket/263

Can we get the fix for this bug added into UTM?

Thanks


This thread was automatically locked due to age.
Parents
  • 0
    Phemmer, thanks for providing the link as it confirmed my suspicion:
    • When switching to UDP I was unable to reproduce this bug. 


    I always configure SSL VPNs with UDP as it makes tunnels that are noticeably faster.  If you already have other SSL VPN tunnels defined and/or SSL VPN Remote Access enabled, the change to UDP will require all Remote Access clients to download the configuration and the generation of all new clients for the site-to-site VPNs.

    Cheers - Bob
Reply
  • 0
    Phemmer, thanks for providing the link as it confirmed my suspicion:
    • When switching to UDP I was unable to reproduce this bug. 


    I always configure SSL VPNs with UDP as it makes tunnels that are noticeably faster.  If you already have other SSL VPN tunnels defined and/or SSL VPN Remote Access enabled, the change to UDP will require all Remote Access clients to download the configuration and the generation of all new clients for the site-to-site VPNs.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    Phemmer, thatnls for providing the link as it confirmed my suspicion:


    I always configure SSL VPNs with UDP as it makes tunnels that are noticeably faster.  If you already have other SSL VPN tunnels defined and/or SSL VPN Remote Access enabled, the change to UDP will require all Remote Access clients to download the configuration and the generation of all new clients for the site-to-site VPNs.

    Cheers - Bob


    We cannot switch to UDP as the corporate firewall here does not allow UDP traffic (and it will be a major battle to try and have it allowed).