SSL issues with new setup

[irbk]

We are doing our actual implmentation of the F5 BigIP LTM VM version 17.1.03 (build 0.0.4).  It's a little bit complcated because we are trying to load balance an application (Microsoft Dynamics Navision 2018) and not just HTTP or HTTPS traffic.  However, for initial testing, one of our servers in the pool being load balanced will at least show an IIS welcome page so I'm testing by just using HTTP/HTTPS.  I have my nodes set up in my pool and I've currently only have the 1 node active that gives an IIS welcome page (the other just gives an error).  I have our wildcard certificate imported and set as the "SSL Profile (Client)" within my virtual server for 443.   If I go directly to http://msnav01.domain.com I get the IIS welcome page.  If I go to http://bigip.domain.com I get the IIS welcome page.  If I go directly to https://msnav01.domain.com I get the IIS wecome page.  If I go to https://bigip.domain.com I eventually get a "site can't be reached" with "err_connection_reset" message.  Checking the LTM log gives me a less-than-useful "SSL Handchange failed" error message and even with the logging turned up I'm not getting much more uesful info
Sep 27 16:53:07 BigIP.domain.com info tmm[3124]: 01dd0002:6: /Common/Wildcard23-24: SSL Handshake details for TCP <client IP>:33343 -> <virtual server IP>:443 entity: server SID: <server sid here> version: TLSv1.2 cipher-suite: ECDHE-RSA-AES128-GCM-SHA256 key-exchange: 333 bytes client-cert-sha1: N/A server-cert-sha1: N/A mutual-authentication: false
I've looked at a lot of different articles but nothing has solved the issue or even helped me move forward.  I've tried turning off the "Generic Alert", setting the Cashe size to 0, turning up the logging to debug, etc.  I'm at a loss and just not sure where to go next.  I'm positive that the issue is something with the cert or the implmentation of the cert, just not sure where to go next.

Thanks in advance!

[Paulius]

@irbk Would you mind sharing the virtual server configuration and any associated configuration such as SSL profile, SSL cert information, and pool member configuration. Based on your explanation the F5 shouldn't have any reason it would work for 1 domain and not the other if the SSL cert is a wildcard for *.domain.com because that includes all FQDNs mentioned. I would recommend running the following tcpdump to see if it provides any additional information.

tcpdump -nni 0.0:nnp host <virtual_server_IP> -w /shared/tmp/ssl_tshoot.pcap

Once you have run your test you can cancel the tcpdump and it should be saved in /shared/tmp/ as ssl_tshoot.pcap. You can copy the pcap off the F5 and open it up in wireshark to see if you can find anything to explain the SSL handshake issue.

[lnxgeek]

Can you post the VS configuration?

[irbk]

What's the easiest way to share the VS config?

[Paulius]

@irbk Go into the CLI and run a "list ltm virtual <virtual_server_name>" and similar commands can be run for each other the other configuration options. To see the other options under "list ltm" you should be able to use the question mark to narrow it down to other pieces of configuration.

[irbk]

Ok, I'm not really a linux guy but I'll do my best!

[irbk]

ltm virtual BigIP_443 {
creation-time 2023-09-26:15:10:23
destination <VS IP>:https
ip-protocol tcp
last-modified-time 2023-09-28:09:52:29
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_443
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Modified_Wildcard {
context clientside
}
Modified_serverssl {
context serverside
}
analytics { }
tcp-analytics { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool BigIP-Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 3
}

The above was just a configuration I was playing around trying to get something like just SSL Passthrough to work.  I think the end goal is the SSL Bridging because you get better traffic analysis and load balancing or something like that.  
This is what the profile was before I started just trying stuff this am.

ltm virtual BigIP-Nav_443 {
creation-time 2023-09-26:15:10:23
destination <VS IP>:https
ip-protocol tcp
last-modified-time 2023-09-28:11:01:52
mask 255.255.255.255
persist {
source_addr {
default yes
}
}
pool Nav_Pool_443
profiles {
LC-http { }
LC-oneconnect { }
LC-tcp-lan { }
Wildcard23-24 {
context clientside
}
analytics { }
tcp-analytics { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
pool BigIP-Nav
type snat
}
translate-address enabled
translate-port enabled
vs-index 3
}

Here is the SSL profile

ltm profile client-ssl Wildcard23-24 {
app-service none
cert-key-chain {
WildCard23-24_0 {
cert WildCard23-24
key WildCard23-24
passphrase <encrypted>
}
}
defaults-from clientssl
inherit-ca-certkeychain true
inherit-certkeychain false
log-ssl-c3d-events debug
log-ssl-client-authentication-events debug
log-ssl-forward-proxy-events debug
log-ssl-handshake-events debug
}

And here is the pool

ltm pool Nav_Pool_443 {
load-balancing-mode predictive-member
members {
Nav01:https {
address <IP>
session monitor-enabled
state up
}
Nav02:https {
address <IP>
session monitor-enabled
state up
}
}
monitor https
}

Thanks again!

[Paulius]

@irbk Based on the second virtual server configuration, I see that you are passing decrypted traffic to the servers on 443. Did you configure the servers to receive decrypted traffic on 443 because by default they should not allow that? Now SSL bridging is nice but not necessary and completely depends on your security stance and capabilities of the receiving pool members and if they can perform all application functions over HTTP and not HTTPS. If it's not required I would stick with SSL termination at the F5 and passing decrypted traffic to the servers.

[irbk]

No, that shouldn't be right.  The servers have to have encrypted traffic, they aren't configured to recive it otherwise.  What setting requres changing?

Actually, the servers arn't even going to be receiving on 443 in the end, this is just how I'm testing to get the certificate issue squared away but the servers do need to recieve encrypted traffic so either the BigIP needs to do a passthrough or we need to setup the SSL Bridging (which I believe is the prefered option for several reasons).

[Paulius]

@irbk So I think we need to sort a few configuration options first.
1. SSL Termination on F5
    F5 terminations SSL using the SSL Client profile and then passes decrypted HTTPS traffic to the server on an alternate port such as 80 or 8080 so that you or the application can tell the difference between traffic that was HTTP traffic and which was HTTPS. So 443(F5) -> 8080(Pool member)
2. SSL Bridging
    F5 terminates SSL using the SSL Client profile, performs varios tasks now that the traffic is decrypted, then finally uses the SSL Server profile to encrypt traffic and pass it back to the pool member on 443 or an alternate port such as 8443.
3. SSL Passthrough
    F5 performs zero SSL tasks and passes the traffic directly to the server to decrypt and encrypt

If you are having an SSL issue it could be directly related to the server not being configured to receive that decrypted traffic since you are only using an SSL client profile or possibly an SSL cert on the server that is rejecting the requests.

[irbk]

End goal is clients will be using a client side application (not a webpage) to go to the F5, the F5 redirects them to the server, client talks with the server.  
How that client side application works is a little bit more tricky.  As far as I can tell, it starts out communicating on 80 and then flips to a different port using TLSv1.2.  The server is expecting it's traffic encrypted so SSL Passthrough or SSL Bridging is my only option and between the two, I guess the SSL Bridging is better because the F5 gets better visability to the traffic.

[irbk]

I didn't know if you might want the profiles as well listed in the VS, so here you go

ltm profile http LC-http {
app-service none
defaults-from http
insert-xforwarded-for enabled
proxy-type reverse
}

ltm profile one-connect LC-oneconnect {
app-service none
defaults-from oneconnect
source-mask 255.255.255.255
}

ltm profile tcp LC-tcp-lan {
app-service none
defaults-from f5-tcp-lan
idle-timeout 28800
}

Yes, that's a really high idle timeout but it was put there becuase people will run reports that run for like 8 hours and we didn't want to system timing them out while a report was running.  I'm not sure if it's necessary but before we can test that we need to get the SSL part working first.

[irbk]

posting the TCPdump is a little bit more tricky.  I think this may be the best way

[lnxgeek]

Looking at the tcpdump it is clear that your problem is that the serverside connection is in cleartext.

It is the job of a serverside ssl profile to make sure that is uses TLS on the connection towards the server (not matter the port number), so that seem to be missing.

[irbk]

Replied to my own reply so things ended up out of order, deleted this comment and added it to the above reply since I can't seem to just "delete" a reply.

[irbk]

Interesting, I was told by our implementer that a "SSL Profile (Server)" was not required.  I'm not quite sure what the proper way to setup the server ssl profile is?  I'm assuming it would match-ish (yea, I'm making up words) the client side?  So something like 

ltm profile server-ssl Modified_serverssl {
app-service none
cert WildCard24
defaults-from serverssl
key WildCard24
log-ssl-c3d-events debug
log-ssl-client-authentication-events debug
log-ssl-forward-proxy-events debug
log-ssl-handshake-events debug
options { no-tlsv1.3 no-dtlsv1.2 }
}

I added in an SSL Profile (server) and the wireshark seems to indicate that I get a good connection.

If I go to https://bigip.domain.com  I don't get a "site can't be reached" with "err_connection_reset" message, instead I get a "Not Found Http error 404" however if I go direct https://msnav01.domain.com  I get the IIS welcome page so I'd expect if the BigIP were working correctly, if I go to https://bigip.domain.com I should be seeing the IIS welcome page.

[Paulius]

@irbk If you intend to reencrypt the traffic that the F5 decrypted and send it to 443 on the pool member you absolutely need an SSL server profile which can use the default profile of clientssl so that the F5 does SSL negotiation between it and the pool member just like the client did between itself and the F5. In regards to your 404 issue, this is most likely occurring because the page you are attempting to reach on 443 is not available. It seems like everything from this point forward is a server side issue rather than an F5 issue.

[irbk]

Currently the BigIP only has 1 pool member, msnav01.domain.com (I've disabled the other one for testing).   If I go direct https://msnav01.domain.com I get the IIS welcome page so I'd expect if the BigIP were working correctly, if I go to https://bigip.domain.com (which can only load balance to msnav01.domain.com) I should be seeing the IIS welcome page. 

[Paulius]

@irbk To make sure I understand. The URL "https://msnav01.domain.com" points directly to the server and URL "https://bigip.domain.com" points to the F5 virtual server? If you are not seeing the IIS page when going to the bigip domain it's most likely that the server is not configured to respond to host "bigip.domain.com" but "msnav01.domain.com" which is why you are receiving the error. Try editing your hosts file to point "msnav01.domain.com" to the IP of the F5 virtual server and see if you are having the same issue. This still seems like a server issue because 404, unless otherwise configured, would only come from the server and not the F5. If you open of dev tools in your browser you can view the HTTP header field "Server" and it will most likely show some variation of "IIS" as the value rather than "BIGIP" which would imply you are making it to the server.

[irbk]

Well, this whole thing may have been a red herring.  @paulj Yes, your understanding correctly.  What I've just realized is that while going to https://msnav01.domain.com  brings up an IIS welcome page going to https://<ip  of msnav01> does NOT bring up an IIS welcome page <facepalm>.  Just to test, I found another server that DID bring up a page when you went to https://<test ip>  and created a new pool for the <test ip> and then adjusted my VS to use the new test IP pool and the thing worked.  So it seems like this whole thing was a failed assumption.  I should have verified that https://<ip  of msnav01> also brought up an IIS welcome page.