'Waiting for TLS handshake' randomly, constantly since Monday
-
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.
-
What browser on what OS? (looks like Windows 10) what version?
-
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
-
Has there been an update to the firewall? What type of firewall/UTM device do you have?
-
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. -
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. -
I've been seeing this a lot on SW, but nowhere else.
-
@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.
-
@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.
-
Do you have any kind of proxy in line?
-
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
-
@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. -
@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.
-
@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.
-
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. -
@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?
-
Yes
-
@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.
-
@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.
-
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):
