Support TLS1.3 and TLS1.2 protocols

Hi MaxMedov , 

In the Client side ssl >>> Bigip will select the best cipher that presented in the client hello which contains all supported ciphers. 
Let say the Client send TLS1.2 ciphers , if the Bigip ip client ssl profile supports TLS1.2 as well TLS1.3 , it will work and the handshake will complete. 
it looks like that bigip picks the one cipher from a pool of supported cipher presented by client hello message. 

But if Big ip doesn't find a supported cipher accorfing to client ssl profile , it will give handshake_failure alert and the ssl connection will not complete. 

Test that in a test virtual server and take a packet captures and look at { Client Hello } samples you will see a list of supported chipher suites and look at the { Server Hello } samples you will see the pivot one or the selected cipher according to your client ssl configurations. 
So 
if a client came with TLS1.2 and your are allowing on bigip ( TLS1.2 or TLS1.3 ) it should accept it but you must allow TLSV1.2 Ciphers in Client ssl profile which attached to your targeted virtual server. 

Also I recommened to take a packet captures first and see which ciphers your clients send in their client hello messages , to make sure you are supporting them.

I will attach a useful Article to troubleshoot in ssl handshakes failure and negotiations : 
https://my.f5.com/manage/s/article/K15292

Hi Mohamed_Ahmed_Kansoh ,
So basically, what you say is that the negotiation process is going only on the ciphers' level, and TLS option of 1.2/1.3 is only to support those ciphers or not.
The clients only see the ciphers that the server offers them and choose from them the strongest one, it could be 1.2 or 1.3

For example:
If I support 6 ciphers (3 of them 1.2 and 3 1.3) and enable TLS1.2 and TLS 1.3 in profile options -
When the client negotiates a connection, if he does have at least 1 cipher version 1.3, the process will proceed with cipher and protocol 1.3
If the client does not have cipher 1.3 from the 3 ciphers 1.3 , but has cipher 1.2 from the list of 3 1.2 ciphers, the negotiations will proceed with this cipher.

In any case, I don't take the ability from the existing client to connect, I just give them another option to use another 3 ciphers with TLS1.3, am I right? 

MaxMedov in addition to what Mohamed_Ahmed_Kansoh has stated. Typically you have an "order" setting on the F5 when defining which SSL ciphers you will use but I do not remember the default setting for this. The following might assist you in verifying what the configuration is through the CLI and how it will appear to the client when it is used.

https://my.f5.com/manage/s/article/K01770517

The two sections are named "Configuring the SSL profile to order SSL ciphers by strength" and "View the SSL cipher order" through the GUI for configuration and CLI for verification of the cipher output. I believe the options for order are the following but I could be wrong on this.

Default
Speed
Strength
FIPS
Hardware

Thank you both!
So at the summary for my case
The negotiation happened with client ciphers > and server ciphers
If I enable 1.3 and 1.2 TLS, the negotiations will happen depending on the strongest cipher chosen it could be 1.2 or 1.3 from the group ciphers of my profile.

MaxMedov - If your post was solved it would be helpful to the community to select *Accept As Solution*. (you may select more than one)
This helps future readers find answers more quickly and confirms the efforts of those who helped.
Thanks for being part of our community.
Lief

Hi, LiefZimmerman I made tests and it seems the results were contrasted above answers.
It seems that if the client supports TLS 1.2 and TLS 1.3
And F5 Supports TLS1.2 and TLS 1.3, BUT does NOT SUPPORT TLS1.3 CIPHERS that the client has, the handshake will fail and the client got reset.
As explained to me, the client should connect with TLS1.2 ciphers if he doesn't find the matched TLS1.3 ciphers. But in fact, it stopped when he didn't find TLS1.3 only.
There is an option called ‘LS Fallback SCSV’ , but only if the client supports it (not relevant for us):
https://community.f5.com/t5/technical-articles/poodle-and-tls-fallback-scsv-deep-dive/ta-p/273803
https://datatracker.ietf.org/doc/html/rfc7507