ML
    • Register
    • Login
    • Search
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups

    'Waiting for TLS handshake' randomly, constantly since Monday

    IT Discussion
    7
    25
    4165
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • momurda
      momurda last edited by

      Randomly, with all websites like ML, SW, Ups.com clients try to connect but get
      'waiting for TLS handshake from domain.com' which never ends. Five minutes later website loads instantly. 5 minutes later it gets stuck with TLS handshake again. Mostly it seems to be from those cdn that every website uses now.
      ssl.google-analytics.com is a problem right now.
      0_1510160710316_efe8dfe3-56ee-40f7-89e7-3623d55a3a59-image.png

      1 Reply Last reply Reply Quote 0
      • Dashrender
        Dashrender last edited by Dashrender

        What browser on what OS? (looks like Windows 10) what version?

        1 Reply Last reply Reply Quote 0
        • momurda
          momurda last edited by

          Seems to be affecting everybody here. I am using firefox with Fall Creators Update, others are still on the Creators Update, may be using edge or Chrome

          1 Reply Last reply Reply Quote 0
          • Dashrender
            Dashrender last edited by

            Has there been an update to the firewall? What type of firewall/UTM device do you have?

            1 Reply Last reply Reply Quote 0
            • momurda
              momurda last edited by

              Watchguard XTM 515 v11.12.4
              On Monday when comcast wasnt working well i started setting up the CenturyLink fiber connection for general use. Currently both are configured in Round Robin Multi Wan, with a weight of 10 for Clink and 1 for Comcast.
              This seems to be working as intended, though it could be the problem.
              The rules for https client policy are From Any Trusted To Any-External.

              1 Reply Last reply Reply Quote 0
              • momurda
                momurda last edited by

                Just noticed lots of these in the log
                2017-11-08 09:32:09 https-proxy 0x8694798-42959 574: 192.168.90.47:52755 -> 216.58.194.198:443 [A txr] {R} | 584: 192.168.90.47:52755 -> 216.58.194.198:443 [!B fc] {B}: failed to connect B channel
                Will report further.

                1 Reply Last reply Reply Quote 0
                • scottalanmiller
                  scottalanmiller last edited by

                  I've been seeing this a lot on SW, but nowhere else.

                  momurda 1 Reply Last reply Reply Quote 0
                  • momurda
                    momurda @scottalanmiller last edited by

                    @scottalanmiller Yes spiceworks is a big problem. Funny i cant get there on my workstation, but a vm i log into gets there no problem. It seems to be some sort of random routing issue. I am trying to force my connection to spiceworks over 2nd WAN as a test but no luck so far.

                    scottalanmiller 1 Reply Last reply Reply Quote 0
                    • scottalanmiller
                      scottalanmiller @momurda last edited by

                      @momurda said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                      @scottalanmiller Yes spiceworks is a big problem. Funny i cant get there on my workstation, but a vm i log into gets there no problem. It seems to be some sort of random routing issue. I am trying to force my connection to spiceworks over 2nd WAN as a test but no luck so far.

                      Most likely, IMHO, they have some app servers on the broken code base and some not.

                      1 Reply Last reply Reply Quote 0
                      • Reid Cooper
                        Reid Cooper last edited by

                        Do you have any kind of proxy in line?

                        1 Reply Last reply Reply Quote 0
                        • JaredBusch
                          JaredBusch last edited by

                          If your load balancer is not working right, you will have problems like this. I would turn it off first.

                          You cannot have SSL going out mulitple connections

                          momurda 1 Reply Last reply Reply Quote 3
                          • momurda
                            momurda @JaredBusch last edited by

                            @jaredbusch This seems to work.
                            May i ask though, what is the point of having 2 WAN connections if unable to use them at the same time? Currently there are a couple always on vpn tunnels through Comcast connection as i havent had time to move them to new CLink yet.
                            Certainly i must have just set something up incorrectly with Multi WAN setup? Though it seems simple enough.
                            Perhaps if i force the client https policy From Any Trusted To CenturyLink WAN instead of Any-External.

                            scottalanmiller 1 Reply Last reply Reply Quote 0
                            • scottalanmiller
                              scottalanmiller @momurda last edited by

                              @momurda said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                              @jaredbusch This seems to work.
                              May i ask though, what is the point of having 2 WAN connections if unable to use them at the same time?

                              Failover.

                              Or other types of load balancing that don't split a single connection.

                              JaredBusch 1 Reply Last reply Reply Quote 0
                              • JaredBusch
                                JaredBusch @scottalanmiller last edited by JaredBusch

                                @scottalanmiller said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                                @momurda said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                                @jaredbusch This seems to work.
                                May i ask though, what is the point of having 2 WAN connections if unable to use them at the same time?

                                Failover.

                                Or other types of load balancing that don't split a single connection.

                                Or as I said, you have your load balancing misconfigured. You can easily load balance as long as all connections from a single internal IP always use the same connection when going to the same destination.

                                1 Reply Last reply Reply Quote 3
                                • momurda
                                  momurda last edited by

                                  Ive changed teh Weight of CLink connection to 100 and left Comcast at 1.
                                  This has mitigated the issue. The B Channel timeouts still happen in the logs but so infrequently that I nor any user has seen the 'waiting for TLS handshake' issue for hours now when browsing.

                                  dbeato 1 Reply Last reply Reply Quote 0
                                  • dbeato
                                    dbeato @momurda last edited by

                                    @momurda said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                                    ight of CLink connection to 100 and left Comcast at 1.
                                    This has mitigated the issue. The B Channel timeouts still happen in the logs but so infrequently that I nor any user has seen the 'waiting for TLS handshake' issue for hours now when browsing.

                                    Are you using round robin for the load balancing?

                                    1 Reply Last reply Reply Quote 0
                                    • momurda
                                      momurda last edited by

                                      Yes

                                      dbeato 1 Reply Last reply Reply Quote 0
                                      • dbeato
                                        dbeato @momurda last edited by

                                        @momurda Okay, so you need to make sure to use "User Source and Destination IP Address binding" That is what I use on my Sonicwall.

                                        travisdh1 1 Reply Last reply Reply Quote 1
                                        • travisdh1
                                          travisdh1 @dbeato last edited by

                                          @dbeato said in 'Waiting for TLS handshake' randomly, constantly since Monday:

                                          @momurda Okay, so you need to make sure to use "User Source and Destination IP Address binding" That is what I use on my Sonicwall.

                                          Yep. On Ubiquiti you need to set the load-balance group to sticky. https://help.ubnt.com/hc/en-us/articles/205145990-EdgeRouter-Dual-WAN-Load-Balance-Feature I've done this at a number of places now, works great.

                                          1 Reply Last reply Reply Quote 2
                                          • momurda
                                            momurda last edited by

                                            In the Watchguard, there is no User Source and Desination IP Address Binding option. There is a Sticky Connections option.
                                            So i think in WG my best option is to force all connections to use CLink at the Policy level. Whats interesting about this setup you can do this for any firewall policy, regardless of your MultiWan settings. I havent enabled this, but it would look like below(this is a snip that i setup but didnt apply to WG):
                                            0_1510247420220_52e49cdb-65cc-4e57-b1b1-d693f774adfe-image.png

                                            dbeato JaredBusch 2 Replies Last reply Reply Quote 2
                                            • First post
                                              Last post