From the latest versions 12.1 and 13.0, SSL3, TLS1.0, TLS1.1 is depreciated. Hence HA communication fails if TLS1.2 remains disabled.
TLS1.2 is not automatically enabled when the instance is upgraded from a lower firmware version.
Hence this must be configured manually.
To fix the “Drive Unavailable” error, perform the following steps:
If issue persists, Trigger the prompt by loading the kernel extension manually
After running this command, open the system preferences in the security pane and see if you can approve the prompt.
While running the above command, if you encounter the “Unable to stage kext” error then perform the action items highlighted below:
The request for resources/list can be very time consuming and can take upto 30 seconds in worst cases (depending on the performance of the network, StoreFront server or other components). This can cause timeout on the Receiver UI. But the response has been received successfully on the Receiver side.
Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.
We can figure out whether this issue is caused by network latency by adding the following registry key on the client:
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixDazzle
Reg_SZ WebUILoadingWatchDogTimeoutMs
WebUILoadingWatchDogTimeoutMs controls the timeout value of watchdog.
Alternately, turn off the Unified Experience in StoreFront (if Receiver 4.4 is being used).
A vulnerability in the DECnet Phase IV and DECnet/OSI protocol processing of Cisco IOS XE Software could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device.
The vulnerability is due to insufficient input validation of DECnet traffic that is received by an affected device. An attacker could exploit this vulnerability by sending DECnet traffic to an affected device. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a DoS condition.
Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-decnet-dos-cuPWDkyL
This advisory is part of the March 2021 release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: March 2021 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication.
Security Impact Rating: High
CVE: CVE-2021-1352
A vulnerability in the CLI command permissions of Cisco IOS and Cisco IOS XE Software could allow an authenticated, local attacker to retrieve the password for Common Industrial Protocol (CIP) and then remotely configure the device as an administrative user.
This vulnerability exists because incorrect permissions are associated with the show cip security CLI command. An attacker could exploit this vulnerability by issuing the command to retrieve the password for CIP on an affected device. A successful exploit could allow the attacker to reconfigure the device.
Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-XE-SAP-OPLbze68
This advisory is part of the March 2021 release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: March 2021 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication.
Security Impact Rating: High
CVE: CVE-2021-1392
To achieve this, we would have to disable the Use Proxy Port option.
To configure the Use Proxy Port setting on a service by using the configuration utility:
To configure the Use Proxy Port setting on a service by using the CLI:
At the command prompt, type:
set service svc -useproxyport NO
The Use Proxy Port option works only when the Use Source IP/ Use Client IP option is enabled on the Service/Service Group respectively.
Also, this option is enabled by default for TCP-based service types, such as TCP, HTTP, and SSL,
This will allow the backend server to see client IP and source port from which the client tries to connect.
in a lot of environments, due to the COVID situation there was spike in access to VPN based services, and in some situations slowness was observed in loading VPN / AAA Login page, to mitigate this problem some changes were done on httpd.conf file (https://support.citrix.com/article/CTX255947).
With a customized httpd.conf (for the above or any other reason), GUI issues can occur, an excerpt from the article below.
WARNING – Following the above solution might result in issues with future firmware upgrades.
When you apply the above configuration, the httpd.conf will not be updated during a future firmware upgrade. This could cause the GUI to become completely unavailable.
If this occurs, you must delete the file /nsconfig/httpd.conf (on both primary and then secondary node), reboot the ADC, and then reapply the below settings.
The clear diagnosis of that issue is that if you run “ps aux | grep httpd” in shell mode, there will be no httpd processes running.
Hi;
I want to have a high availability cluster of two Proxy SG devices that are not of the same hardware model. Is this possible.
There is no load balancing here. It is just the failover group.
Kindly
Wasfi
I am trying to get either the 32 bit or 64 bit LInux client to run from a USB. I marked it as executable but neither version does anything when executed.
Any suggestions?
Hello fellows,
is there any way how we can debug requests that are denied because of an invalid_request? For example to see if an header is malformed and in what way.
For HTTP connections we can of course capture the whole connection stream, but what about HTTPS connections? Is there a debug log where ProxySG is providing such information?