BIG-IP
10537 TopicsSSL Client Certification Alert 46 Unknown CA
We are seeing 'Alert 46 Unknown CA' as part of the initial TLS handshake between client & server. From a wireshark capture, the 1st Client Hello is visible, followed by the 'server hello, certificate, server key exchange, certificate request, hello done'. As part of this exchange, TLS version 1.2 is agreed, along with the agreed cypher. The next packet in the flow is an ACK from the source, followed by Alert (Fatal), Description: Certificate Unknown. I cannot see anywhere in the capture a certificate provided by the client This behaviour occurs regardless of the client authentication/client certificate setting (ignore/request/require). I have ran openssl s_client -connect x.x.x.x:443 as a test (from the BIG-IP) and I see the server side certs and 'No client certificate CA names sent' which is expected as no client cert sent. The end client has not reinstalled the client certificate as yet (3 day lead time). Are there any additional troubleshooting steps I can undertake to confirm the client is either rejecting the server certificate and therefore not returning the client certificate? Kind RegardsSolved28KViews0likes17CommentsDifferences between Disabled vs. Force Offline (Pool Member)
I find the distinctions between Disabled vs. Force Offline somewhat unclear in certain detail. Both options sounds graceful wherein all existing connections are allowed to timeout and not brute force dropped? Does persistence session refer to a persistence record? https://support.f5.com/csp/article/K13310 When set to Disabled, a node or pool member continues to process persistent and active connections. It can accept new connections only if the connections belong to an existing persistence session. When set to Forced Offline, a node or pool member allows existing connections to time out, but no new connections are allowed. I'm running a Big-IP LTM running 12.1.2 HF2. We have an ongoing issue with a backend webserver that is a Pool Member of a Http Pool. Behaviour I need is maintain existing connections even after Pool Member has been "Forced Offlined" Should I go with Force Offline?Solved19KViews0likes3CommentsTCP 3-WAY Handshake vs TCP Half-Open
1. TCP 3-Way handshake – TCP is a connection-oriented protocol, a connection needs to be established before two devices can communicate. TCP uses a process called three-way handshake to negotiate the sequence and acknowledgment fields and start the session. Here is a graphical representation of the process. The three way handshake process consists of three steps: a. Host A initiates the connection by sending the TCP SYN packet to the destination host. The packet contains the random sequence number (e.g. 5432) which marks the beginning of the sequence numbers for data that the Host A will transmit. b. The Server receives the packet and responds with its own sequence number. The response also includes the acknowledgment number, which is Host A’s sequence number incremented by 1 (in our case, that would be 5433). a. Host A acknowledges the response of the Server by sending the acknowledgment number, which is the Server’s sequence number incremented by 1. Post TCP 3 way handshake, the data transfer starts. After the data transmission process is finished, the connection will get terminated by sending FIN (FINISHED) flag which does graceful termination of connection. TCP Half Open connection – TCP connections are called Half Open connections when the third step of the 3-Way handshake sending final ACK to the server fails (as shown in below figure) or if one of the hosts closes the connection without acknowledging the other. Half Open connection process is given below – 1. Host initializes the request by sending SYN packet. 2. Server replies to the client with SYN_ACK, and at this point server reserves some resource for the client and waits for the final ACK to arrive (Acknowledgment message). 3. However, the client does not respond to the server with final Acknowledgment. So an established connection is said to be "half-open" if one of the TCPs has closed or aborted the connection at its end without the knowledge of the other, or if the two ends of the connection have become desynchronized owing to a crash that resulted in loss of memory. Such connections will automatically become reset if an attempt is made to send data in either direction. However, half-open connections are expected to be unusual. F5 TCP-Half Open monitor – F5 also have TCP-Half Open monitor available under Local trafficàMonitors. Tcp_half_open monitor is most widely used for gateway monitoring when you just need to ensure the socket is responding to connection requests and desire the lowest overhead on the monitoring target. The tcp_half_open monitor sends a SYN packet to the pool member, and if a SYN-ACK is received from the server in response, the pool member is marked UP. There are few use cases to use TCP-half open monitor as given below – For example, a webserver would be less impacted by a half open connection request that is immediately reset than a connection that completes the entire open and close handshake sequence. Another common use for the tcp_half_open monitor is to prevent the application from spewing a bunch of log messages indicating connections were opened but not used. It should be noted that some applications cannot gracefully handle the half open connection and subsequent reset, so some testing should be done in order before implementing this monitor. There is option available to test same under ‘Test’ tab shown in above image. Under Test tab, you can put webserver IP alongwith its associated port. And it will show Test results and it can be confirmed if application supports TCP-Half open or not. Do test same in your environment and share your observations. I hope, this article helps you. Your inputs, suggestions or questions are always welcome. MayurSolved17KViews2likes8CommentsPing from source ip address
Hi, I have F5 LTMs in our production environment. I assign the two different ip addresses on two interfaces (1.1,1.2) 1.1 --> 10.1.1.1 1.2 --> 20.1.1.1 The default route on the F5 is (0.0.0.0 0.0.0.0 10.1.1.10) i want to ping the IP 30.1.1.1 using the source ip of 1.1 interface(10.1.1.1). Kindly tell me the command how to do that ? thanks.17KViews0likes4Commentsresetting lost/forget admin and root password on F5 BIG IP
Can anyone suggest how to reset the forgotten root and admin password on F5 BigIP devices( running on 11.x and 10.x versions) Do we need need to provide same password for root and admin? How does it work for a HA pair. We have two devices in redundant. Do we need to set same passwords on both devices for root and admin account?12KViews0likes26CommentsError processing HTTP request header
I'm running into an issue on my apache tomcat 8 servers when receiving traffic routed through the F5. We have enabled TLS on the application servers and have setup an SSL Server profile to send the traffic through over HTTPS. The pool is configured to send the traffic to the servers on ports 8443 and 8444. However we are getting the following error from the servers. 2019-03-20 05:26:32,938+0000 INFO org.apache.coyote.http11.Http11Processor service - Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:462) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) I am not certain what to look at on the F5 for how it is formatting/encrypting the traffic before it sends it onto the servers. Any advice on the direction I should take this would be very much appreciated.11KViews0likes9CommentsF5 Server SSL Profile using TLS 1.0 instead of TLS 1.2
Hi I have an F5 virtual server that does SSL inspection so it has a client ssl profile and a server ssl profile. The backend server is running on a Windows Server 2019 / IIS and it only accepts TLS 1.1 and 1.2 clients. Since the F5 acts as a client in this case towards the Windows Server 2019, I have created a server ssl profile which forces the F5 to use TLS 1.2 only (SSL Proxy is disabled). My problem is that during the Client Hello from the F5 towards the Windows Server, TLS 1.0 is used. So the backend server immediatelly sends a RST ACK without sending Server Hello for supported ciphers etc. While doing a capture on Wireshark, I saw that TLS 1.0 is used. And further down in the same TCP packet it mentions TLS 1.2. This is driving me crazy. Is there any way we can enforce F5 to use 1.2 only during Client Hello?Solved11KViews0likes32CommentsConnection Resets from F5
Hi Has anyone experienced a similar issue as i am having with my F5 I have VIP setuo to handle http connections for one of my sites. but users report getting a err conn rest message on chrome and firefox. i have replucated the issue on my machine and it seems you have to hit the url on the server 4-5 times and it chucks a conn reset to the user. i performed a wireshark capture and got the below BIG-IP: [0x23f168a:700] Flow expired (sweeper) (idle timeout) when i see the tcp rst cause. log i get the following Mar 23 10:58:57 lb1a-cpt err tmm[17861]: 01230140:3: RST sent from 10.0.91.96:80 to 196.43.208.62:55300, [0x23c0eba:9280] {peer} TCP retransmit timeout I dnt know where lese to have a look as i have looked at the tcp profile and disabled tcp rst cause.log and i am sill receiving a conn reset and this happens in less than a minute I appreciate all input to help diagnose this issue11KViews0likes8Comments