'Waiting for TLS handshake' randomly, constantly since Monday
-
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):
-
-
@momurda said in 'Waiting for TLS handshake' randomly, constantly since Monday:
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):It depends on what you want. Your stated goal was load balancing. The watchguard can do it if you set it up properly. You did not do it properly and had problems. This is not a surprise.
But that does not mean to then not use load balancing at all.
It mean go back and RTFM and set it up properly.
Conveniently, you do not even have to RTFM because @dbeato has posted the instructions for you.
-
@jaredbusch said in 'Waiting for TLS handshake' randomly, constantly since Monday:
.
Ive already set sticky connections in the Global MultiWan.
The override option for this policy cant be enabled. -
@momurda But did you increase the default timeout from 3 minutes to let's say 10 minutes or so?
-
@dbeato Yes, 10 minutes actually, some time this morning.
