Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

SSL Error

Hi Guys,

While requesting https://URL, we are getting an below error in browsers.

ssl_error_no_cypher_overlap

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hey Mohammed

I'm afraid we need more information than that.

  1. Do you see it in all browsers?
  2. Does it appear when trying to reach the WebGUI of the BIG-IP or applications serviced through the BIG-IP?
  3. What type cipher suites do you support? What is defined in the Client SSL profile?
  4. Does it affect all or selected applications?
0
Comments on this Answer
Comment made 2 months ago by Mohammed M Irfan 116

Hi Philip,

Thanks for instant reply!

  1. Do you see it in all browsers? Yes, In all browsers Like: Chorme, Firefox and Internet Explore.

  2. Does it appear when trying to reach the WebGUI of the BIG-IP or applications serviced through the BIG-IP? Applications Services, when we enter https://URL.

  3. What type cipher suites do you support? What is defined in the Client SSL profile? Can you please explain on this questions?

We have configured the standard type of VS and port:443 CA certificate is applied on Client SSL Profile.

Source Addr persistence is applied

0
Comment made 2 months ago by Mohammed M Irfan 116

Hi Philip,

In Pcap i found the below information!

Client in Client Hello Packet

Cipher Suites (19 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

BIGIP in Server Hello Packet

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I agree with Phillip, We need more data from you. However the error message you see may indicates that ciphers proposed by a client are not supported on big-ip if you doing SSL offload.

If you are not doing ssl offload then you need to contact your application team to solve that.

0
Comments on this Answer
Comment made 2 months ago by Mohammed M Irfan 116

Hi Surgeon,

We are doing SSL Offload at BIG-IP.

How to cross verify the ciphers proposed by a client and how to calculate that BIG-IP support or not.

0
Comment made 2 months ago by Mohammed M Irfan 116

Hi,

I have capture the pcap, TCP Handshake is successful and SSL Handshake is too but after SSL Handshake next frame is reset packet. TCP Dumps Output:

1. TCP  166 IN  s1/tmm0 : 59098 → 443 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1380 WS=64 TSval=988937946 TSecr=0 SACK_PERM=1
2. TCP  184 OUT s1/tmm0 : 443 → 59098 [SYN, ACK, ECN] Seq=0 Ack=1 Win=4140 Len=0 MSS=1460 TSval=823640073 TSecr=988937946 SACK_PERM=1
3. TCP  176 IN  s1/tmm0 : 59098 → 443 [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSval=988937995 TSecr=823640073
4. TLSv1.2  693 IN  s1/tmm0 : Client Hello
5. TCP  176 OUT s1/tmm0 : 443 → 59098 [ACK] Seq=1 Ack=518 Win=4657 Len=0 TSval=823640128 TSecr=988937997
6. TLSv1.2  278 OUT s1/tmm0 : Server Hello, Change Cipher Spec
7. TLSv1.2  221 OUT s1/tmm0 : Encrypted Handshake Message
8. TCP  176 IN  s1/tmm0 : 59098 → 443 [ACK] Seq=518 Ack=103 Win=65535 Len=0 TSval=988938049 TSecr=823640129
9. TCP  176 IN  s1/tmm0 : 59098 → 443 [ACK] Seq=518 Ack=148 Win=65535 Len=0 TSval=988938050 TSecr=823640130
10. TLSv1.2 227 IN  s1/tmm0 : Change Cipher Spec, Hello Request, Hello Request
11. TCP 176 OUT s1/tmm0 : 443 → 59098 [ACK] Seq=148 Ack=569 Win=4708 Len=0 TSval=823640183 TSecr=988938050
12. TCP 176 OUT s1/tmm0 : [TCP Dup ACK 20#1] 443 → 59098 [ACK] Seq=148 Ack=569 Win=4708 Len=0 TSval=823640183 TSecr=988938050
13. TLSv1.2 717 IN  s1/tmm0 : Application Data
14. TCP 176 OUT s1/tmm0 : 443 → 59098 [ACK] Seq=148 Ack=1110 Win=5249 Len=0 TSval=823640184 TSecr=988938050
15. TCP 189 443 → 59098 [RST, ACK] Seq=148 Ack=1110 Win=0 Len=0 [F5RST: No route to host]

Last reset packet, cause: No route to host

this information make me confused.

0
Comment made 2 months ago by surgeon

Please check if you have routes to your pool members. Big-ip can not reach them. The error message clearly said that - [F5RST: No route to host]

0
Comment made 2 months ago by Philip Jonsson 952

Surgeon is right, if you are missing routes to the host then it will surely not work. You need to make sure you have that in place.

0
Comment made 2 months ago by Mohammed M Irfan 116

Hi Surgeon,

Default routes to the host is configured.

I have two default routes in BIG-IP

One is in control plan, default routes (i.e. Management VLAN).

[root@BIG-IP_A_v13:Active:Standalone] config # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.10.2       0.0.0.0         UG    0      0        0 VLAN-X
0.0.0.0         10.1.1.1        0.0.0.0         UG    9      0        0 mgmt
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 mgmt
10.1.10.0       0.0.0.0         255.255.255.0   U     0      0        0 VLAN-X
127.1.1.0       0.0.0.0         255.255.255.0   U     0      0        0 tmm
127.7.0.0       127.1.1.253     255.255.0.0     UG    0      0        0 tmm
127.20.0.0      0.0.0.0         255.255.0.0     U     0      0        0 tmm_bp

One is in Data plan, default routes (i.e. VLAN-X).

root@(BIG-IP_A_v13)(cfg-sync Standalone)(Active)(/Common)(tmos)# list net route
net route external_default_gateway {
    gw 10.1.10.2
    network default
}
-1
Comment made 2 months ago by Thiyagu 183

Hi Mohammed M Irfan, Could you please share the command syntax which you have used on F5 to capture the following output?

TCP 166 IN s1/tmm0 : 59098 → 443 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1380 WS=64 TSval=988937946 TSecr=0 SACK_PERM=1 2. TCP 184 OUT s1/tmm0 : 443 → 59098 [SYN, ACK, ECN] Seq=0 Ack=1 Win=4140 Len=0 MSS=1460 TSval=823640073 TSecr=988937946 SACK_PERM=1 3. TCP 176 IN s1/tmm0 : 59098 → 443 [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSval=988937995 TSecr=823640073

Thanks a lot in advance.

Regards, Thiyagu

0
Comment made 1 month ago by Mohammed M Irfan 116

Hi Thiyagu,

Please find the below tcpdump commands.

tcpdump -vvv -s0 -nni 0.0:nnnp host 192.168.1.2 -w /var/tmp

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hey Mohammed

You mentioned in other thread that you have multiple RD's. Do you have route domains configured? Because this means that the BIG-IP will have separate routing tables for the VLANs assigned to the respective VLANs.

You wrote the following: "Two vlans created and tagged with interface 1.1, both vlans are on different RD."

0
Comments on this Answer
Comment made 1 month ago by Mohammed M Irfan 116

Hi Philip,

Apologies for delay in reply!!

Let me give the detail of my VE configuration.

  1. Created two RD for different solutions.
  2. Yes, two VLANs is configured which is tagged and interface 1.1 is used, one for RD1 and one for RD2 of respective solutions.
  3. Their is only a single interface is used i.e. 1.1
  4. No TRUNK configure.
  5. In both solutions: Client to LB:VIP and LB to Backend servers are L3 connectivity.
  6. To reach Backend Servers a default route is configured.

Issue is:

When client hits the request to LB:VIP which is captured in tcpdump as shared above but that traffic is not forward to respective pool members.

Troubleshoot:

If ping to backend servers it get the response. If we see the tracepath it taking to the destination from Management GW.

I am not getting the answer why it is happening and i crossed verified VS, Pool configurations multiple times.

0
Comment made 1 month ago by Philip Jonsson 952

Hey Mohammed

Just to clarify.

  1. You use your BIG-IP in a one-arm mode, meaning you only use one interface?
  2. On this interface you have created two tagged VLANS?
  3. Are you experiencing problems for just one route domain or both?

When you are pinging, what interface are you using? If I remember correctly, the BIG-IP will use the interface based on the routing table. You can define a source interface or IP address by using the -I flag. Please see below:

Ping from the MGMT interface fails because it does not have a route to that network:

[root@bigip1:Active:Standalone] config # ping -I 10.64.180.245 172.16.20.1
PING 172.16.20.1 (172.16.20.1) from 10.64.180.245 : 56(84) bytes of data.
^C
--- 172.16.20.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7770ms

Ping from Internal Server VLAN is successful because it has a route to that network:

[root@bigip1:Active:Standalone] config # ping -I 172.16.1.31 172.16.20.1
PING 172.16.20.1 (172.16.20.1) from 172.16.1.31 : 56(84) bytes of data.
64 bytes from 172.16.20.1: icmp_seq=1 ttl=64 time=2.65 ms
64 bytes from 172.16.20.1: icmp_seq=2 ttl=64 time=1.04 ms
64 bytes from 172.16.20.1: icmp_seq=3 ttl=64 time=1.31 ms
^C
--- 172.16.20.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2425ms
rtt min/avg/max/mdev = 1.047/1.671/2.651/0.702 ms
[root@bigip1:Active:Standalone] config #

Since you are receiving a "No Route to host" error, we need to make sure both route domains have routes to the back-end servers. When using route domains, there are two commands you should remember using, the rdsh and the rdexec. This let's you run commands from a different route domain.

It uses the following syntax:

rdexec <route domain id> <command> [<arguments>]

For example:

rdexec 10 ping 10.0.0.2

K13472: Userland applications on a BIG-IP system can now connect to hosts in non-default route domains

Try and ping from both route domains and see if that works. If it does not work, add the route manually under Network > Routes.

1
Comment made 1 month ago by Mohammed M Irfan 116

Hi Philip,

  1. You use your BIG-IP in a one-arm mode, meaning you only use one interface?

    Yes, Using one-arm mode (i.e. interface 1.1).
    
  2. On this interface you have created two tagged VLANS?

    Yes, One interface 1.1 we have created two tagged Vlans.
    
  3. Are you experiencing problems for just one route domain or both?

    For one route domain we are facing the problem, and 
    For second one its working fine (i.e. traffic is forwarded to backend servers) but if i run tracepath command trace the path, its show next hop is from management network.
    

We have added the route for specific network with respective vlan gateway in cli. which is reflecting in GUI too. (Network > Routes)

I will follow both steps too.

rdexec 10 ping x.x.x.x 
config # ping -I 172.16.1.31 172.16.20.1

Thanks..

Mohammed

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Try a more simple cipher suite, in SSL profile, for example DEFAULT:!DHE:!3DES

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi,

You configured tagged vlan within BIGIP VE???

How is configured your hypervisor’s vswitch?

In VE, it is recommended to disable tagging, or you must configure ESXi vswitch with vlan id 4095

https://kb.vmware.com/s/article/1004252

0
Comments on this Answer
Comment made 1 month ago by Mohammed M Irfan 116

Hi Stanislas,

You configured tagged vlan within BIGIP VE???

    Yes, both RD Vlans.

How is configured your hypervisor’s vswitch?

    Passed the vlan-ids on vswitch for respective traffic.
0
Comment made 1 month ago by Stanislas Piron 10106

Passed the vlan-ids on vswitch for respective traffic.

What does it mean?

What is your hypervisor?

0
Comment made 1 month ago by Mohammed M Irfan 116

Hi Stanislas,

How is configured your hypervisor’s vswitch?

    1. standard switch act as L2 and
    2. Distributed switch act as L3.

In VE, it is recommended to disable tagging, or you must configure ESXi vswitch with vlan id 4095

    Yes, VMware team configured vlan-id 4095.
0