Forum Discussion
Effrum
Nimbostratus
NimbostratusOneconnect behavior while updating server certificates
I imagine this sort of situation isn't THAT unique, so I'm hoping to maybe find some guidance haha.
We have a VS that uses SSL-Bridging and Oneconnect. The server teams were renewing certificates on each of the pool members without a maintenance window (take 1 member down, update the cert, bring it back up and let it rejoin the pool). However, once the new certs were in place, users began reporting issues with connecting to the VS and the application.
My understanding is that the certs were exactly the same, and they were only renewed on the pool members themselves (the client SSL cert wasn't changed, so the users shouldn't even be aware of the change). I could just be reaching at straws here, but my one thought is that maybe the available Oneconnect TCP connections for those members were still in-use. The servers weren't brought down long enough for the Max Age to expire the connections.
I would imagine that if the F5 attempted to send encrypted traffic that the server didn't honor, it would tear down the connection and make a new one. However, I'm not finding any documentation that explains exactly how Oneconnect connections are torn down (other than the assumption of expiring via age, and I did see another DevCentral post talking about 404's will cause a Oneconnect connection to get torn down).
The information in this KB article and its related articles (https://support.f5.com/csp/article/K7208) and other DevCentral searches didn't seem to point me in the right direction. Does anyone have a link or other information on how Oneconnect tears down or handles connections when the underlying SSL connection has changed?
Vijay_ECirrus
My understanding is that the F5 doesn't care about underlying SSL connection with OneConnect. The backend TCP/SSL connection is pre-established and is not torn down but used for new HTTP requests from a client that matches OneConnect parameters. However, when you take down a pool member (i.e., the member fails health-check and is marked down), after the relevant time period, F5 will recognize the member being down and stop sending new connections to member marked down. F5 may continue utilizing the existing connection to send requests to the down member. One way to work around this is to set the "Action on Service Down" to reselect or reject depending on your application.