Oscar Moyano Gomariz Posted February 21, 2019 Share Posted February 21, 2019 I've configured load balancing for SMTP and works OK but OWA,rpc doesnt work - Exchange 2019 - NetScaler VPX version 12.05620nc (Express license) My configuration is: #Create servers add server EXCHVTX01. 10.1.0.60 add server EXCHVTX02. 10.1.0.61 #Create monitors add lb monitor mon_smtp SMTP add lb monitor mon_owa HTTP-ECV -send "GET /owa/healthcheck.htm" recv 200 -LRTM DISABLED -secure YES add lb monitor mon_activesync HTTP-ECV -send "GET /Microsoft-Server-ActiveSync/healthcheck.htm" recv 200 -LRTM DISABLED -secure YES add lb monitor mon_rpc HTTP-ECV -send "GET /rpc/healthcheck.htm" recv 200 -LRTM DISABLED -secure YES ... #Create Service Groups add serviceGroup svcgrp_ex2019_smtp_25 TCP add serviceGroup svcgrp_ex2019_smtp_465 TCP add serviceGroup svcgrp_ex2019_smtp_587 TCP add serviceGroup svcgrp_ex2019_imap_143 TCP add serviceGroup svcgrp_ex2019_imap_993 TCP add serviceGroup svcgrp_ex2019_owa SSL add serviceGroup svcgrp_ex2019_activesync SSL add serviceGroup svcgrp_ex2019_rpc SSL #Bind Service Groups bind servicegroup svcgrp_ex2019_smtp_25 EXCHVTX01 25 bind servicegroup svcgrp_ex2019_smtp_25 EXCHVTX02 25 bind serviceGroup svcgrp_ex2019_smtp_25 -monitorName mon_smtp bind servicegroup svcgrp_ex2019_smtp_465 EXCHVTX01465 bind servicegroup svcgrp_ex2019_smtp_465 EXCHVTX02 465 bind serviceGroup svcgrp_ex2019_smtp_465 -monitorName mon_smtp bind servicegroup svcgrp_ex2019_smtp_587 EXCHVTX01 587 bind servicegroup svcgrp_ex2019_smtp_587 EXCHVTX02 587 bind serviceGroup svcgrp_ex2019_smtp_587 -monitorName mon_smtp bind servicegroup svcgrp_ex2019_owa EXCHVTX01 443 bind servicegroup svcgrp_ex2019_owa EXCHVTX02 443 bind serviceGroup svcgrp_ex2019_owa -monitorName mon_owa bind servicegroup svcgrp_ex2019_activesync EXCHVTX01 443 bind servicegroup svcgrp_ex2019_activesync EXCHVTX02 443 bind servicegroup svcgrp_ex2019_activesync -monitorName mon_activesync bind servicegroup svcgrp_ex2019_rpc EXCHVTX01 443 bind servicegroup svcgrp_ex2019_rpc EXCHVTX02 443 bind servicegroup svcgrp_ex2019_rpc -monitorName mon_rpc .... The config (image1) with effective status DOWN Next: #Create Load Balancer add lb vserver lb_vsrv_ex2019_smtp_25 TCP 10.1.0.62 25 add lb vserver lb_vsrv_ex2019_smtp_465 TCP 10.1.0.62 465 add lb vserver lb_vsrv_ex2019_smtp_587 TCP 10.1.0.62 587 add lb vserver lb_vsrv_ex2019_imap_143 TCP 10.1.0.62 143 add lb vserver lb_vsrv_ex2019_imap_993 TCP 10.1.0.62 993 add lb vserver lb_vsrv_ex2019_owa SSL 0.0.0.0 0 -persistenceType NONE add lb vserver lb_vsrv_ex2019_activesync SSL 0.0.0.0 0 -persistenceType SRCIPDESTIP add lb vserver lb_vsrv_ex2019_rpc SSL 0.0.0.0 0 -persistenceType SOURCEIP -timeout 30 .. #Bind Service Groups to vServer bind lb vserver lb_vsrv_ex2019_smtp_25 svcgrp_ex2019_smtp_25 bind lb vserver lb_vsrv_ex2019_smtp_465 svcgrp_ex2019_smtp_465 bind lb vserver lb_vsrv_ex2019_smtp_587 svcgrp_ex2019_smtp_587 bind lb vserver lb_vsrv_ex2019_imap_143 svcgrp_ex2019_imap_143 bind lb vserver lb_vsrv_ex2019_imap_993 svcgrp_ex2019_imap_993 bind lb vserver lb_vsrv_ex2019_owa svcgrp_ex2019_owa bind lb vserver lb_vsrv_ex2019_activesync svcgrp_ex2019_activesync bind lb vserver lb_vsrv_ex2019_rpc svcgrp_ex2019_rpc .. #Bind SSL certificate bind ssl vserver lb_vsrv_ex2019_owa -certkeyName 'MycertWilcard' bind ssl vserver lb_vsrv_ex2019_activesync -certkeyName 'MycertWilcard' bind ssl vserver lb_vsrv_ex2019_rpc -certkeyName 'MycertWilcard' bind ssl vserver lb_vsrv_ex2019_ews -certkeyName 'MycertWilcard' conf in image2 next Content swith etc but the basic configuration doesn't work Unlike SMTP - all green lights there - the virtual server and Service Groups for OWA,RCP,Activesync etc has a red light for both Status and Effective Status. I've changed the DNS entry for "mail" (as in mail.mydomain.net/owa) to point 10.1.0.60 or 10.1.0.61 and all is fine but with the VIP on the NetScaler not..... I used this guide: https://citrixguyblog.com/2017/07/22/citrix-netscaler-loadbalancing-exchange-20132016-walkthrough-guide/ hank you in advance! Link to comment Share on other sites More sharing options...
CarlStalhood Posted February 21, 2019 Share Posted February 21, 2019 Is TLS 1.0 disabled on the Exchange servers? I wonder if your ADC is missing the TLS 1.2 ciphers in the default backend cipher group. Is the default SSL profile enabled on your appliance? If so, you can add ciphers to the default backend profile. Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted February 21, 2019 Author Share Posted February 21, 2019 38 minutes ago, Carl Stalhood1709151912 said: Is TLS 1.0 disabled on the Exchange servers? I wonder if your ADC is missing the TLS 1.2 ciphers in the default backend cipher group. Is the default SSL profile enabled on your appliance? If so, you can add ciphers to the default backend profile. Hi! Yes TLS 1.0 and TLS 1.1 disabled on both servers. TLS 1.2 active. My NS default cipher (image) What another feateure or configuration can I check it? Thanks a lot Carl Link to comment Share on other sites More sharing options...
CarlStalhood Posted February 21, 2019 Share Posted February 21, 2019 I don't see any TLS 1.2 ciphers in that list. Create a new Cipher Group with TLS 1.2 ciphers and bind it to your service groups. Or I think newer builds of NetScaler 12.0 or 12.1 add the missing TLS 1.2 ciphers. Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted February 21, 2019 Author Share Posted February 21, 2019 28 minutes ago, Carl Stalhood1709151912 said: I don't see any TLS 1.2 ciphers in that list. Create a new Cipher Group with TLS 1.2 ciphers and bind it to your service groups. Or I think newer builds of NetScaler 12.0 or 12.1 add the missing TLS 1.2 ciphers. I created the new cipher group. How I can bind it to the service group? For the default SSL profile . Is enabled. It's ok ? Link to comment Share on other sites More sharing options...
CarlStalhood Posted February 21, 2019 Share Posted February 21, 2019 Your SSL Service Group should have a Cipher section. Remove the current ciphers and then bind the new cipher group. I normally enable default SSL Profile, which affects all SSL vServers and Service Groups. Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted February 21, 2019 Author Share Posted February 21, 2019 7 minutes ago, Carl Stalhood1709151912 said: Your SSL Service Group should have a Cipher section. Remove the current ciphers and then bind the new cipher group. I normally enable default SSL Profile, which affects all SSL vServers and Service Groups. Yes..I enabled ssl default profile and now in all the vserves and service groups are: SSL Profile SSL Profilens_default_ssl_profile_frontend It's done...bind my group cipher group with TLS1.2 to my owa service group.... But anything change......red. thanks Carl! Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted February 21, 2019 Author Share Posted February 21, 2019 My ssl parameters: Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted February 22, 2019 Author Share Posted February 22, 2019 Updates.. After check it yesterday and this morning....same problem. OWA does't work......I dont find the problem... Link to comment Share on other sites More sharing options...
Todd Harrington Posted February 26, 2019 Share Posted February 26, 2019 Try to do a "sh servicegroup <name of a service group that is not working> and report back what it says the probe failure was under "Last Response" Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted March 4, 2019 Author Share Posted March 4, 2019 I tried the same with storefront server and same problem... Netscaler 12 new deployement... Monitor Name: StoreFront State: DOWN Passive: 0 Probes: 30 Failed [Total: 30 Current: 30] Last response: Failure - Probe failed. Link to comment Share on other sites More sharing options...
Todd Harrington Posted March 4, 2019 Share Posted March 4, 2019 You could be comparing apples to oranges in the above example, but it could also be related. Let's narrow the focus. If you are using a monitor type of "Storefront" that specific monitor type is scripted and is running a script attempting to check the services on the back end server specific to Storefront. Do you get the same failure message "Probe Failed" on your OWA monitors? Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted March 5, 2019 Author Share Posted March 5, 2019 20 hours ago, Todd Harrington said: You could be comparing apples to oranges in the above example, but it could also be related. Let's narrow the focus. If you are using a monitor type of "Storefront" that specific monitor type is scripted and is running a script attempting to check the services on the back end server specific to Storefront. Do you get the same failure message "Probe Failed" on your OWA monitors? error message: Failure - Time out during SSL handshake stage if I change the monitor to "no secure" so the error message is: Failure - TCP connection successful, but application timed out Link to comment Share on other sites More sharing options...
Eugene Loh1709158410 Posted March 6, 2019 Share Posted March 6, 2019 This may be an issue / bug with VPX not handling backend ssl even with ciphers that you have configured / listed. Someone on another post mention this. https://discussions.citrix.com/topic/388325-netscaler-12-rfc-5746-on-backend-bug-limitation/?page=0#comment-1975755 You can check if your build has the supported TLS1.2 cipher you need. https://docs.citrix.com/en-us/netscaler/12-1/ssl/ciphers-available-on-the-citrix-adc-appliances Also your VIP / LB wont come up until your Service Group comes up. Not ideal but you can look changing from SSL type to TCP type for you SG/LB/CS Link to comment Share on other sites More sharing options...
Manoj Rana Posted March 6, 2019 Share Posted March 6, 2019 I am sure you have already checked and install the SSL certificate on all of your backend server. Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted March 6, 2019 Author Share Posted March 6, 2019 42 minutes ago, Manoj Rana said: I am sure you have already checked and install the SSL certificate on all of your backend server. Yes, the certificates are installed Link to comment Share on other sites More sharing options...
Manoj Rana Posted March 11, 2019 Share Posted March 11, 2019 have you tried to restart the IIS services? and I hope you are using HTTPS monitor. Thanks Manoj Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted March 11, 2019 Author Share Posted March 11, 2019 27 minutes ago, Manoj Rana said: have you tried to restart the IIS services? and I hope you are using HTTPS monitor. Thanks Manoj Yes of course! https monitor and I tried to restart IIS etc. Link to comment Share on other sites More sharing options...
Manoj Rana Posted March 14, 2019 Share Posted March 14, 2019 What is your netscaler build number ? in case any bug in the build. Link to comment Share on other sites More sharing options...
Oscar Moyano Gomariz Posted March 14, 2019 Author Share Posted March 14, 2019 45 minutes ago, Manoj Rana said: What is your netscaler build number ? in case any bug in the build. NS12.0.56.20.nc I don't know...but I have problema with storefront monitor too. (finally I use https-ecv) and exchange owa monitor for the moment not work.....i'm balancing my exchange servers by dns round robin Link to comment Share on other sites More sharing options...
Eric Vegter Posted March 26, 2020 Share Posted March 26, 2020 Hello, has this client-hello / RST issue ever been solved? We are running in to the same situation. Exchange 2019 backed servers operating successfully and no issues handling TLS handshakes with 'regular' clients when using a hosts file to connect to the IIS OWA website. When the Netscaler VPX (v12.x or v13.x) tries to connect to the /owa/healthcheck.htm in the healthmonitor (or any other L4 or L7 monitor) it does'n't work. We tried many many combinations in the presented ciphers and TLS support on the backend servers and netscaler but nothing brings the healthmonitor alive. Also, when we use a simple TCP based monitor, and then the service comes up, there are issues reported in for example Chrome or the SSL Labs test that insecure ciphers are used. As that Netscaler Virtual Server is serving as the frontend for the client (chrome, ..) that indicates the problem is on the NS side. Using the same chrome browser and a hosts file entry pointing to the exch2019 backend gives no warnings etc. Any solutions for this? Rgds, Eric Link to comment Share on other sites More sharing options...
Todd Harrington Posted March 26, 2020 Share Posted March 26, 2020 3 hours ago, Eric Vegter said: Hello, has this client-hello / RST issue ever been solved? We are running in to the same situation. Exchange 2019 backed servers operating successfully and no issues handling TLS handshakes with 'regular' clients when using a hosts file to connect to the IIS OWA website. When the Netscaler VPX (v12.x or v13.x) tries to connect to the /owa/healthcheck.htm in the healthmonitor (or any other L4 or L7 monitor) it does'n't work. We tried many many combinations in the presented ciphers and TLS support on the backend servers and netscaler but nothing brings the healthmonitor alive. Also, when we use a simple TCP based monitor, and then the service comes up, there are issues reported in for example Chrome or the SSL Labs test that insecure ciphers are used. As that Netscaler Virtual Server is serving as the frontend for the client (chrome, ..) that indicates the problem is on the NS side. Using the same chrome browser and a hosts file entry pointing to the exch2019 backend gives no warnings etc. Any solutions for this? Rgds, Eric Eric, Check this article out, we had a similar issue, not exact, and it caused havoc in our load balancing environment. https://support.citrix.com/article/CTX264377 I ultimately worked with our exchange admins to disable the use of EMS (Extended Master Secret) on the exchange servers and all probe messages cleared up. Link to comment Share on other sites More sharing options...
Oluwasegun Kolawole Posted March 29, 2020 Share Posted March 29, 2020 Hi @omoyano Have you been able to resolve this issue ? I have the same exact issue with exchange 2019 and i am running VPX 13.0 latest build. Can someone please help. Thanks Serge Link to comment Share on other sites More sharing options...
Oluwasegun Kolawole Posted March 30, 2020 Share Posted March 30, 2020 @Oscar Moyano Gomariz Below is the solution to your problem. I ran into the same exact issue and this is what fixed it for me. If the Windows Server has this registry setting: (Tested on windows server 2019 ) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoClients"=dword:00000000 "AllowInsecureRenegoServers"=dword:00000000 Netscaler Monitor will fail to communicate with the exchange services you're trying to put behind the CSVS no matter what settings you use. After i deleted the registry settings it works fine. NetScaler monitor is able to probe the backend Reading RFC 5745 I am guessing Netscaler does not utilize RFC 5746 Extension properly in the “TLS Client Hello” resulting in a TCP Reset from the Windows Servers Hope this helps. I found fix on this thread: https://discussions.citrix.com/topic/388325-netscaler-12-rfc-5746-on-backend-bug-limitation/#comment-1975755 1 Link to comment Share on other sites More sharing options...
Eric Vegter Posted March 30, 2020 Share Posted March 30, 2020 The suggested registry keys to 'unharden' the TLS handshaking indeed solves the problem for the netscaler 12.x version. For v13 it is working with the hardening in place, but for that to work you have to set the SSL profile block renegotiation setting to insecure only. You can do that in the global advanced settings or in a custom SSL profile you bind to for example the service group. Thanks all for contributing! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now