Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 7659 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 Issue ( TCP/UDP: Closing socket )

Sami Alio
Dears , would you please help me solving the below ,
i am using ASG120 , Upgraded to 9 , using SSL VPN / TCP/ 443 
the ASG is in Syria now , i tried to connect from UAE , i failed due to the below :

Sun May 05 16:25:58 2013 OpenVPN 2.1.1 i686-w64-mingw32 [SSL] [LZO2] built on Oct 15 2012
Sun May 05 16:25:58 2013 MANAGEMENT: TCP Socket listening on 127.0.0.1:25341
Sun May 05 16:25:58 2013 Need hold release from management interface, waiting...
Sun May 05 16:25:58 2013 MANAGEMENT: Client connected from 127.0.0.1:25341
Sun May 05 16:25:58 2013 MANAGEMENT: CMD 'state on'
Sun May 05 16:25:58 2013 MANAGEMENT: CMD 'log all on'
Sun May 05 16:25:58 2013 MANAGEMENT: CMD 'hold off'
Sun May 05 16:25:58 2013 MANAGEMENT: CMD 'hold release'
Sun May 05 16:26:03 2013 MANAGEMENT: CMD 'username "Auth" "admin"'
Sun May 05 16:26:03 2013 MANAGEMENT: CMD 'password [...]'
Sun May 05 16:26:03 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sun May 05 16:26:03 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun May 05 16:26:03 2013 LZO compression initialized
Sun May 05 16:26:03 2013 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun May 05 16:26:03 2013 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
Sun May 05 16:26:03 2013 Local Options hash (VER=V4): '619088b2'
Sun May 05 16:26:03 2013 Expected Remote Options hash (VER=V4): 'a4f12474'
Sun May 05 16:26:03 2013 Attempting to establish TCP connection with 77.44.174.69:443
Sun May 05 16:26:03 2013 MANAGEMENT: >STATE:1367756763,TCP_CONNECT,,,
Sun May 05 16:26:09 2013 TCP connection established with 77.44.174.69:443
Sun May 05 16:26:09 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun May 05 16:26:09 2013 TCPv4_CLIENT link local: [undef]
Sun May 05 16:26:09 2013 TCPv4_CLIENT link remote: 77.44.215.69:443
Sun May 05 16:26:09 2013 MANAGEMENT: >STATE:1367756769,WAIT,,,
Sun May 05 16:26:10 2013 MANAGEMENT: >STATE:1367756770,AUTH,,,
Sun May 05 16:26:10 2013 TLS: Initial packet from 77.44.174.69:443, sid=63c31b3f e0bfe7cc
Sun May 05 16:26:10 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun May 05 16:26:52 2013 Connection reset, restarting [-1]
Sun May 05 16:26:52 2013 TCP/UDP: Closing socket
Sun May 05 16:26:52 2013 SIGUSR1[soft,connection-reset] received, process restarting
Sun May 05 16:26:52 2013 MANAGEMENT: >STATE:1367756812,RECONNECTING,connection-reset,,
Sun May 05 16:26:52 2013 Restart pause, 5 second(s)
Sun May 05 16:26:57 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Sun May 05 16:26:57 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sun May 05 16:26:57 2013 Re-using SSL/TLS context
Sun May 05 16:26:57 2013 LZO compression initialized
Sun May 05 16:26:57 2013 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sun May 05 16:26:57 2013 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
Sun May 05 16:26:57 2013 Local Options hash (VER=V4): '619088b2'
Sun May 05 16:26:57 2013 Expected Remote Options hash (VER=V4): 'a4f12474'
Sun May 05 16:26:57 2013 Attempting to establish TCP connection with 77.44.174.699:443
Sun May 05 16:26:57 2013 MANAGEMENT: >STATE:1367756817,TCP_CONNECT,,,
Sun May 05 16:27:01 2013 TCP connection established with 77.44.174.69:443
Sun May 05 16:27:01 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun May 05 16:27:01 2013 TCPv4_CLIENT link local: [undef]
Sun May 05 16:27:01 2013 TCPv4_CLIENT link remote: 77.44.174.69:443
Sun May 05 16:27:01 2013 MANAGEMENT: >STATE:1367756821,WAIT,,,
Sun May 05 16:27:01 2013 MANAGEMENT: >STATE:1367756821,AUTH,,,
Sun May 05 16:27:01 2013 TLS: Initial packet from 77.44.174.69:443, sid=b635b5d1 84d59471
Sun May 05 16:27:01 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

and freezes again for 20-30 seconds then giving : 
Connection reset, restarting
TCP/UDP: Closing socket


any ideas / help please , shall i use another ports , or another type of connection or encryption to speed up the connection itself ?

Regards ,


This thread was automatically locked due to age.
  • 0
    Since i upgraded the Astort to 8 then to 9 , and this problem appeared !
    i think there is a bug regarding TLS negotiation ...

    Please help me solving this ,
    Regards ,
  • 0
    Sami, please also show the log from the other side for the same connection attempt.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Dear Bob , 
    you always help me , thanks for your reply ,
    would you please explain what shall i do exactlly , the above is from user side , do you need what firewall show ?

    Regards
  • 0
    here it is , from Firewall side :

    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: MULTI: multi_create_instance called
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Re-using SSL/TLS context
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: LZO compression initialized
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Local Options hash (VER=V4): 'a4f12474'
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Expected Remote Options hash (VER=V4): '619088b2'
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: TCP connection established with 37.123.68.117:50880
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: Socket Buffers: R=[131072->131072] S=[131072->131072]
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: TCPv4_SERVER link local: [undef]
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: TCPv4_SERVER link remote: 37.123.68.117:50880
    2013:05:06-01:37:52 ASG120-1 openvpn[4932]: 37.123.68.117:50880 TLS: Initial packet from 37.123.68.117:50880, sid=92c330c9 7b614877
    2013:05:06-01:38:52 ASG120-1 openvpn[4932]: 37.123.68.117:50880 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    2013:05:06-01:38:52 ASG120-1 openvpn[4932]: 37.123.68.117:50880 TLS Error: TLS handshake failed
    2013:05:06-01:38:52 ASG120-1 openvpn[4932]: 37.123.68.117:50880 Fatal TLS error (check_tls_errors_co), restarting
    2013:05:06-01:38:52 ASG120-1 openvpn[4932]: 37.123.68.117:50880 SIGUSR1[soft,tls-error] received, client-instance restarting
    2013:05:06-01:38:52 ASG120-1 openvpn[4932]: TCP/UDP: Closing socket


    Regards ,
  • 0
    TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

    Try what I call Rule #1 (enhanced):

    Whenever something seems strange, always check the Intrusion Prevention,
    Application Control and Firewall logs.


    Any luck?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Now the log on user side is : 


    ---------------------------
    Mon May 06 21:04:56 2013 MANAGEMENT: CMD 'log all on'
    Mon May 06 21:04:56 2013 MANAGEMENT: CMD 'hold off'
    Mon May 06 21:04:56 2013 MANAGEMENT: CMD 'hold release'
    Mon May 06 21:05:11 2013 MANAGEMENT: CMD 'username "Auth" "Athahabee"'
    Mon May 06 21:05:11 2013 MANAGEMENT: CMD 'password [...]'
    Mon May 06 21:05:11 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
    Mon May 06 21:05:11 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Mon May 06 21:05:12 2013 LZO compression initialized
    Mon May 06 21:05:12 2013 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
    Mon May 06 21:05:12 2013 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
    Mon May 06 21:05:12 2013 Local Options hash (VER=V4): '619088b2'
    Mon May 06 21:05:12 2013 Expected Remote Options hash (VER=V4): 'a4f12474'
    Mon May 06 21:05:12 2013 Attempting to establish TCP connection with 77.44.215.69:443
    Mon May 06 21:05:12 2013 MANAGEMENT: >STATE:1367863512,TCP_CONNECT,,,
    Mon May 06 21:05:12 2013 TCP connection established with 77.44.215.69:443
    Mon May 06 21:05:12 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
    Mon May 06 21:05:12 2013 TCPv4_CLIENT link local: [undef]
    Mon May 06 21:05:12 2013 TCPv4_CLIENT link remote: 77.44.174.69:443
    Mon May 06 21:05:12 2013 MANAGEMENT: >STATE:1367863512,WAIT,,,
    Mon May 06 21:05:13 2013 MANAGEMENT: >STATE:1367863513,AUTH,,,
    Mon May 06 21:05:13 2013 TLS: Initial packet from 77.44.174.69:443, sid=02e3e3ee 8587c133
    Mon May 06 21:05:13 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Mon May 06 21:06:12 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Mon May 06 21:06:12 2013 TLS Error: TLS handshake failed
    Mon May 06 21:06:12 2013 Fatal TLS error (check_tls_errors_co), restarting
    Mon May 06 21:06:12 2013 TCP/UDP: Closing socket
    Mon May 06 21:06:12 2013 SIGTERM[soft,tls-error] received, process exiting
    Mon May 06 21:06:12 2013 MANAGEMENT: >STATE:1367863572,EXITING,tls-error,,
  • 0
    Dear Bob ,
    the Intrusion log is empty , also the application control , 
    while the firewall is contains something like :




    now if i tried the connection from any part inside Syria , it worked , maybe since the ASG120 is installed there , but if i tried it from Jordan or UAE or Qatar , it failed .


    2013:05:06-21:04:04 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53046" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:06 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53047" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:07 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53048" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:10 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53049" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:11 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53050" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:13 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53051" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:14 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53052" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:16 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53053" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:17 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53054" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:19 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53055" dstport="4444" tcpflags="SYN" 
    2013:05:06-21:04:20 ASG120-1 ulogd[4221]: id="2002" severity="info" sys="SecureNet" sub="packetfilter" name="Packet accepted" action="accept" fwrule="60006" initf="tun0" srcip="10.242.2.6" dstip="192.168.2.3" proto="6" length="52" tos="0x00" prec="0x00" ttl="128" srcport="53056" dstport="4444" tcpflags="SYN"



    shall i downgrade to V7 , i remember it was working well before upgrading to 8 then 9 .

    Regards ,
  • 0
    The lines you show from the Firewall log all represent packets accessing WebAdmin that were accepted from someone connected via SSL VPN.

    Downgrading doesn't make sense - there's no one else reporting such an issue.  There's no question that the packets are being blocked somewhere outside the UTM.  Are you certain that the firewall on the client is not blocking?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    You may want to run a tcpdump on both sides of the tunnel to see if there are any anomalous packets showing up.  I've seen several interesting situations where people inside of certain countries start receiving anomalous Reset packets that neither side transmitted indicating that shenanigans are taking place. If this is the case, you may want to be careful about troubleshooting further for the sake of the person inside of that country.

    What you would be looking for in your tcpdump is any reset packet that was received by one or both sides, that was not transmitted from either side.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML