macOS里的Microsoft Edge浏览器错误代码6

昨天更新macOS10.15.6到Safari14.0以后,发现Microsoft Edge浏览器不能使用了,打开后就显示错误代码6.

错误代码6

并且右上角会挨个弹出所安装的插件不能使用。

查找微软社区里有相关问题反馈 https://answers.microsoft.com/zh-hans/microsoftedge/forum/all/macos-10156-microsoft/bd885458-7566-47db-b223-e758d7135a39?rtAction=1600425417892&tm=1600425432912

有人提到了重启macOS可以解决问题,尝试重启系统后发现问题暂时解决。

所以Safari更新为什么会导致Edge不能用呢?

尝试绕过ESXi最小4GB内存的安装检查

声明:此文使用的方法在很早的版本ESXi安装时就有人使用过,可以绕过检查,但并不推荐在小内存机器上安装ESXi。

更新说明:如果安装过程遇到图2的内存检查错误时再使用此方法,有些朋友反映在图1处显示为3.6G内存时,安装一会就会显示一个紫色背景的错误消息,根本进不到后续的操作步骤,这种情况就无法使用此方法了。

有些机器本身是4G内存,也许因为部分内存被核显使用,或者需要被BMC/BIOS/UEFI预留,或者其它ESXi的计算方法,会在启动是显示为3.xGB内存,这样因为差一点点内存不能使用ESXi还是有点可惜的,就可以想办法绕过内存检查脚本。

方法步骤如下:

1. U盘启动安装ESXi,在黄色背景界面看到内存为3.7GiB(我使用物理ESXi嵌套安装,分配的3.75GiB内存)。

识别到3.7 GiB内存

2. 同意协议,选择安装介质,设置密码等一系列操作后,遇到内存检查错误,提示需要4.00 GiB。

内存检查错误

3. 在上图界面键盘按下ALT+F1,进入下图界面,然后用户名root,密码为空(之前设置的密码还未生效)。

ALT+F1进入Shell

4. 执行如下命令切换到检查脚本所在目录。

cd /usr/lib/vmware/weasel/util

5. 备份原有脚本,设置权限, 然后vi修改。

mv upgrade_precheck.py upgrade_precheck.py.bak

cp upgrade_precheck.py.bak upgrade_precheck.py

chmod 666 upgrade_precheck.py

vi upgrade_precheck.py

6. vi编辑器中搜索 “MEM_MIN_SIZE”,在vi中输入/MEM_MIN_SIZE。

vi搜索MEM_MIN_SIZE

7. 第一次搜索命中结果应该定位到如下图光标位置。

第一次命中结果

8.我们要修改的就在下方,使用光标定位到下面或者在搜索时按下n键去找第二次命中应该就是了。

需要修改的部分

9. 定位光标到第一个4后面,按i进入编辑模式,退格删除4,修改为2。

修改最小内存为2GiB

10. 按ESC进入命令模式,输入:wq,回车保存退出。

11. 执行下面的命令(杀掉当前的python进程)。

kill -9 $(ps -c | grep weasel | grep -v grep | awk ‘{print $1}’)

12. 然后就又回到熟悉的安装界面了。

回到安装界面

13. 一系列操作后,原来的内存检查错误界面不会出现了,出现了擦除安装介质的对话框,F11继续。

没有再次出现内存检查错误

14. 然后就是等进度条啦。

开始等进度条

15. 安装结束,提示拔下ESXi安装盘,比如U盘,然后回车重启。

安装完成

16. ESXi重启加载完毕后。

重启完毕

17. 访问ESXi网页控制台,3.75 GB内存正常使用。

3.75GiB正确识别并启动成功

ESXi直通核显

常见的ESXi直通显卡都是直通独立显卡给Linux,macOS或者Windows,这样接上显示器,直通USB键鼠以后使用体验和物理机相差就很小了。也不需要通过VMware Remote Console或者VNC,RDP等形式远程访问了。

我们买的工控机或者NUC,Mac Mini等用来玩ESXi的设备往往都是有核显的,在ESXi中核显除了在开机自检过程中被ESXi获取一次控制权或者用户需要连上显示器查看ESXi的DCUI界面(熟悉的ESXi黄色背景后台)之外,显卡并不会作为硬件设备被ESXi虚拟化后提供给虚拟机使用。(ESXi目前被官方支持的显卡虚拟化只支持Nvidia Grid,也就是说跟消费者级别显卡无缘)。

为了让仅有的核显发挥余热,我们就可以尝试把它直通给虚拟机,做硬解使用。(目前测试发现ESXi下直通的核显无法外接显示器使用。

尝试的步骤如下:

1. 在Hardware->PCI Devices中,选中核显,点击Toggle passthrough,如果提示重启请重启ESXi。如图,我的是UHD 630.

直通核显

2. 在将设备添加到虚拟机之前,设置好虚拟机的远程访问,如Windows的RDP,macOS的Screen Sharing或者Linux的VNC,防止直通核显后VMware Remote Console访问有问题。

我以虚拟的macOS举例,所以打开macOS中的Screen Sharing,配置好可以访问的用户,记住地址。

3. 编辑虚拟机,添加PCI设备,或动态PCI设备。选择该核显,然后预留所有内存,保存设置。

添加PCI device

4. SSH访问ESXi,运行esxcli system settings kernel set -s vga -v FALSE(当不需要直通核显时记得改回来,把FALSE改成TRUE执行一下),让ESXi启动时不去获取显卡控制权,然后重启ESXi。

5. 重启ESXi之后,启动macOS虚拟机。然后通过Screen Sharing去远程访问它。登陆进去以后,查看System Report中的Graphics,应该如图一样可以同时看到虚拟显卡和直通的核显。

系统中可以看到直通的核显

Tips: 如上设置后,DCUI界面不能直接访问了,可以通过如下操作借用SSH访问:

1)SSH连接ESXi

2)输入TERM=xterm。(mac的终端需要,windows下的Putty等不需要)

3)输入dcui

这时就看到熟悉的DCUI界面了,如果想退出可以在shell中Ctrl+C结束dcui。

ESXi直通USB键鼠

使用ESXi时,我们有时会直通网卡或者显卡给虚拟机使用,让虚拟机独占该物理设备,减少虚拟化造成的性能损耗,相关教程网上也比较多。今天我们来尝试下直通USB键鼠,这样虚拟的桌面系统(Windows,Linux,macOS等)就可以配合直通显卡接显示器以后直接当一台物理机使用了。

1. 首先要查询USB键鼠的VID和PID,在windows,macOS系统上插上设备查询或者插在ESXi主机上利用lsusb查询都可以。

查询设备pid和vid

图中是vid在前,pid在后。Cypress这个是我的Filco键盘,Dell这个就是个鼠标。

2. 通过ESXi网页终端来编辑虚拟机的高级设置或者ssh到ESXi修改虚拟机的vmx文件,加入允许USB HID设备开关和具体直通的USB设备id。

编辑设置->虚拟机选项->高级->编辑配置。

编辑配置

添加如下参数,vid在前,pid在后。确定,保存。

添加参数

3. ssh访问ESXi,并使用vi修改/etc/vmware/config,  加入上面添加的要直通的设备ID。

添加直通USB设备ID

4. 如上设置后下次ESXi重启时VMkernel还会获取设备的控制权,我们需要到ESXi启动引导中禁用掉VMkernel对上述设备获取控制权。

ssh到ESXi里,使用vi修改/bootbank/boot.cfg, 在启动参数后面加上CONFIG./USB/quirks=0x04b4:0x120d::0xffff:UQ_KBD_IGNORE:0x413c:0x301a::0xffff:UQ_KBD_IGNORE

(顺序为vid:pid::0xfff)

修改ESXi启动引导参数

保存后重启ESXi,然后我们就可以编辑虚拟机设置来添加USB键鼠设备了。

5. 添加其它设备,USB设备,自动会同时创建一个USB控制器,键鼠用USB2.0即可。

添加USB设备

6. 保存后启动该虚拟机系统,如果直通了显卡并外接显示器,那么就可以直接看着显示器里该系统启动,并且可以使用USB键鼠来操作了。

在虚拟机中lsusb查看直通的USB键鼠

以上操作步骤参考了troubleshooting-device-passthrough-with-vmware-workstation-and-vmware-fusion, how-to-passthrough-usb-keyboard-mouse-hid-and-ccid-devices-to-vm-in-esxi 和 passthrough-usb-devices-from-esxi-to-vm

另外,此方法并非官方推荐的做法,根据 https://kb.vmware.com/s/article/1021345,官方更加建议使用一个PCI插槽的USB controller (上面有USB 接口), 把整个controller设备直通给VM ,然后让虚拟机系统来识别连接在上面的USB设备。适用于常见的USB设备如键鼠,耳麦,智能卡读卡器,U盾等。除了主机板载的USB controller之外,类似的PCI USB controller如下面的型号都可以使用:

NEC chipset PCI-E usb3 controller(Chipset: NEC d720200, model:MC210)

Ti chipset PCI-E usb3 controller

远程访问ESXi网页控制台

安装完ESXi之后,最常用的管理方式就是访问ESXi的网页控制台,在局域网里访问很简单,直接访问ip就行了,比如https://192.168.1.99。如果不在局域网里该如何远程访问呢?

首先,宽带最好有公网IP,(动态的要配好DDNS),如果没有公网IP,要使用frp之类的做内网穿透。我这里拿最简单的有公网IP并配好DDNS来举例,假设我宽带公网IP使用DDNS绑定的域名是home.abc.com。

其次,要在宽带光猫或者桥接以后拨号的路由器上做端口转发。这里拿桥接以后用来拨号的路由器来举例。先弄明白需要转发的目标地址和端口号,目标地址就是ESXi所用的192.168.1.99,根据https://ports.vmware.com/home/vSphere,vSphere Web Client使用TCP 443和902来做Client connections。所以我们转发这两个端口就可以了。

需要转发的目标端口

国内运营商在大部分地区都封禁了个人宽带的443,80等端口。我们就要用其它端口来转发443。我在我的路由器里做出如下端口转发规则:

端口转发规则

有些路由器会对端口转发规则自动设置入站的防火墙规则,这种情况下设置了如上端口转发规则以后就可以通过https://home.abc.com:9443在外网访问ESXi网页控制台了。

有些路由器(比如我使用的UBNT ER-X路由器),端口转发进来的流量还要加防火墙入站规则,于是我加了如下防火墙规则:

防火墙规则

假如想限制特定的外网IP段来访问此ESXi,那么可以在防火墙规则中设置Source IP,我这里留空(允许所有外网IP访问)。

现在通过一台外网的机器(连接手机运营商4G网络)来访问https://home.abc.com:9443。

没有为该域名申请证书

因为我没有为该域名申请证书,所以访问时提示不安全,我们点“继续前往”。

访问ESXi网页

使用管理员账号密码登录并切换到虚拟机管理。

虚拟机管理页面

点击黑色预览窗口,使用浏览器控制台访问该虚拟机。

使用浏览器控制台访问虚拟机

一切使用正常。如遇到其它功能使用有问题,建议查阅上面提到的端口列表网页,检查是否有其他端口需要做转发。

最后,从安全实践来考量,把ESXi控制台直接暴露在公网访问并不是一个推荐的做法,建议在路由器上启用L2TP等VPN服务,在外网时,机器先通过L2TP VPN连入内网,然后通过https://192.168.1.99的局域网地址访问ESXi。

如何不让ESXi7.0的虚拟闪存占掉你的小硬盘

在ESXi7中,根据https://docs.vmware.com/cn/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html的如下说明:

ESXi7.0 安装或升级的存储要求

要安装 ESXi 7.0,USB 或 SD 设备的引导设备至少需要为 8 GB,其他设备类型的引导设备至少需要为 32 GB。要升级到 ESXi 7.0,引导设备至少需要为 4 GB。从本地磁盘、SAN 或 iSCSI LUN 引导时,要求具有 32 GB 磁盘以便能够创建系统存储卷,其中包括引导分区、引导槽和基于 VMFS-L 的 ESX-OSData 卷。ESX-OSData 卷负责旧版 /scratch 分区、VM-tools 和核心转储目标的工作。
建议的 ESXi 7.0 安装选项如下所示:
    8 GB USB 或 SD 以及额外的 32 GB 本地磁盘。ESXi 引导分区位于 USB 或 SD 上,ESX-OSData 卷位于本地磁盘上。
    至少具有 32 GB 的本地磁盘。该磁盘包含引导分区和 ESX-OSData 卷。
    本地磁盘为 142 GB 或更大。该磁盘包含引导分区、ESX-OSData 卷和 VMFS 数据存储。
ESXi 7.0 系统存储卷最多可占用 138 GB 的磁盘空间。仅当本地磁盘设备至少有 4 GB 的额外可用空间时,才会创建 VMFS 数据存储。要与本地 VMFS 数据存储共享引导设备,您需要使用 142 GB 或更大的本地磁盘。
如果找不到本地磁盘,则 ESXi 7.0 会在降级模式下运行,即某些功能处于禁用状态,且 /scratch 分区位于 RAM 磁盘上并链接到 /tmp。您可以重新配置 /scratch 以使用单独的磁盘或 LUN。为实现最佳性能和内存优化,请勿在降级模式下运行 ESXi。
升级到 ESXi 7.0 的过程会对引导设备重新进行分区,将原始核心转储、locker 和暂存分区整合到 ESX-OSData 卷中。如果未配置自定义核心转储目标,则默认核心转储位置为 ESX-OSData 卷中的一个文件。

按照官方文档,如果我们想用的硬盘既做系统分区,又想把剩余空间做Datastore,那么至少需要分配142GB空间。小于142GB时则不能创建Datastore。实测使用140G HDD硬盘时稍有出入,但可见Datastore空间VMFS只有12G左右,OSDATA Volume大概占用120G.

HDD硬盘设备分区显示
ESXi命令行下filesystem 显示

如果所用硬盘是SSD(我分配了128G),OSDATA Volume默认还是大概占用120G,文件系统是VFFS,在ESXi web控制台中查看被用作了虚拟闪存。

ESXi引入虚拟闪存已经好多年了,虚拟闪存用作ESXi主机交换缓存,从而提升在该主机上运行的虚拟机的性能,为虚拟机提供读缓存,提升虚拟机的存储性能。

SSD硬盘设备分区显示
ESXi命令行下filesystem 显示
虚拟闪存占用120G

在企业所用的服务器环境中,这点硬盘占用不算什么,但是对于一些使用比较小的硬盘来做ESXi的系统硬盘的home lab玩家,假如被占用如此多的空间来做系统分区或者虚拟闪存,那Datastore空间就会吃紧了。

解决办法:

官方没有提供给用户如何去不使用虚拟闪存的文档,但其实ESXi提供了autoPartitionOSDataSize这个启动参数用来调整ESXi的系统分区大小。调整的是OSDATA这个Volume的大小。我们来试试这个参数能否节省我们的硬盘空间。

先来试试HDD,我同样使用140G HDD,在如下启动界面,按下Shift+O,加上autoPartitionOSDataSize=8192,然后回车。

启动界面
加上OSDataSize参数

安装完成之后检查硬盘占用,VMFS Datastore大概有124G,OSDATA Volume仅占用8G左右(我们设置的8192)

HDD硬盘设备分区显示
ESXi命令行下filesystem 显示

再来试试SSD,我还是来分配128G,也加上autoPartitionOSDataSize=8192,安装完成后检查硬盘占用VMFS Datastore大概有112G, OSData Volume仅占用8G左右(我们设置的8192).

SSD硬盘设备分区显示
ESXi命令行下filesystem 显示

查看虚拟闪存仅占用8G左右

虚拟闪存占用8G

问题解决。

综合上面的测试,最根本的原因是ESXi7的系统分区OSData默认会占用120G左右硬盘空间,不管是HDD还是SSD,而当硬盘是SSD时,还会将此空间作为虚拟闪存,所以我们的解决方案就是调整系统的OSData分区大小。

此文参考了https://www.virtuallyghetto.com/2020/05/changing-the-default-size-of-the-esx-osdata-volume-in-esxi-7-0.html的相关内容和官方发行说明。

在安装有ESXi的NUC10i7FNH上升级BIOS历险记

今年上半年疫情在家办公期间,购入了一台NUC10i7FNH用来装ESXi做home lab,一直运行良好,前几天发现该机器的BIOS有更新了(FN0044.cap),于是选择把虚拟机都关闭,ESXi进入维护模式,关机。

把cap文件复制到U盘里,插在NUC上,开机按F7进入BIOS升级模式,升级一切顺利,完成后自动重启机器,加载ESXi系统,进度条马上要结束时,显示错误消息:

Shutting down firmware services…

Using ‘simple offset’ UEFI RTS mapping policy

马上上网搜索,发现这个问题以前在NUC8i7HNK更新BIOS之后出现过,当时的解决方案是Intel后来出了新版本BIOS。。。

可我这已经是最新版本了,难道要等Intel修复?另外还搜索到有人建议把UEFI mode禁用进入legacy mode,可是NUC10 BIOS设置里,这两个是灰色不可设置的(UEFI mode启用, legacy mode禁用)。😓

等了几分钟,错误消息还在NUC外接屏幕上显示着,我尝试从其它机器ping了下ESXi,通了,又尝试ssh,也成功连上了,于是

TERM=xterm

dcui

在shell中显示ESXi后台的界面,发现ESXi貌似没啥问题,如下图


Intel NUC10i7FNH 运行ESXi7.0

访问ESXi网页,退出维护模式,开启虚拟机,一切运行正常。

PS: NUC10安装ESXi可以参考https://www.virten.net/2020/03/esxi-on-10th-gen-intel-nuc-comet-lake-frost-canyon/ 和 https://www.virten.net/2020/03/intel-nuc-recommended-bios-settings-for-vmware-esxi/

ESXi社区版ne1000 VIB驱动的更新

原文出自https://www.virtuallyghetto.com/2020/08/enhancements-to-the-community-ne1000-vib-for-intel-nuc-10.html本篇是征求原作者同意后的简要中文翻译。

使用Intel NUC 10(寒霜峡谷)做ESXi主机的玩家应该知道ESXi默认自带的驱动不能识别板载的Intel i219V(8086:0d4f)网卡,需要使用一个社区版的ne1000驱动来封装ESXi ISO进行安装。因此而造成的副作用就是当给ESXi打补丁或者升级时,这个社区版的ne1000驱动会被默认的新版本驱动替换,导致网卡再次无法被ESXi识别。

一个变通的办法是再次安装这个社区版的ne1000 VIB,网络连接就可以恢复了。还可以通过创建vSphere Image Profile来把补丁或者升级包中的驱动用社区版ne1000 VIB替换,再进行补丁或升级安装。原作者在和Songtao(另一个VMware的工程师,USB Network Native Driver for ESXi的开发者)交流后,Songtao提供了一个非常简单的解决方案。这个办法就是给社区版ne1000 VIB取一个不同的名字,这样社区版ne1000 VIB就可以和默认的驱动共存了,更重要的一点,打补丁或者升级ESXi之后它也会一直保留。

下面是信的社区版 ne1000 VIB (离线包):

https://download3.vmware.com/software/vmw-tools/Intel-NUC-ne1000_0.8.4-3vmw.670.0.0.8169922-offline_bundle-16654787.zip

使用vSphere Image Builder UI工具或者PowerCLI版的Image Builder来封装离线包的详细指南可以参考这篇博客(英文)。

最后,一些网友在相关网站中提出对一些其它版本的i219网卡支持的需求,Songtao在此次驱动更新中,添加了如下i219网卡版本的支持:

8086:0d4e – Ethernet Connection (10) I219-LM

8086:0d4f – Ethernet Connection (10) I219-V

8086:0d4c – Ethernet Connection (11) I219-LM

8086:0d4d – Ethernet Connection (11) I219-V

8086:0d53 – Ethernet Connection (12) I219-LM

8086:0d55 – Ethernet Connection (12) I219-V

8086:15fb – Ethernet Connection (13) I219-LM

8086:15fc – Ethernet Connection (13) I219-V

8086:15f9 – Ethernet Connection (14) I219-LM

8086:15fa – Ethernet Connection (14) I219-V

8086:15f4 – Ethernet Connection (15) I219-LM

8086:15f5 – Ethernet Connection (15) I219-V

8086:1a1e – Ethernet Connection (16) I219-LM

8086:1a1f – Ethernet Connection (16) I219-V

8086:1a1c – Ethernet Connection (17) I219-LM

8086:1a1d – Ethernet Connection (17) I219-V

这些额外的版本支持除了因为来自社区的用户反馈,还因为这些设备都是i219家族的网卡,但这并不意味着对其它网卡的改进或者支持。希望使用i219家族网卡的用户能从这次更新中获益。

Custom Thumbprints for Horizon 7

Custom thumbprints allow the use of separate certificates for Blast TCP and VMware Tunnel connections since VMware Unified Access Gateway 3.4, the configuration can be done in the UAG administrative console or through PowerShell INI, according to https://techzone.vmware.com/blog/whats-new-vmware-unified-access-gateway-34.

Before this improvement, Horizon native client would encounter certificate thumbprint mismatch issue if you are using Nginx to reverse proxy to an Unified Access Gateway for Horizon View.

Here’s an example:

Reverse Proxy: nginx.bj.st

UAG: 10.117.43.230 gateway-04.uag.com (and the backend interface is in 172.16/16 subnet which connect to Horizon Connection Server)

Horizon Connection Server: 172.16.1.104 rp-01.uag.com

Disable Tunnel and BSG on Horizon Connection Server.

Enable Tunnel and BSG on UAG, external url using nginx.bj.st

Nginx configuration:

Create a configuration file for Nginx as /etc/nginx/endtoendencryption.conf:

stream {
    upstream UAGserverGroup {
        # Please make sure the correct IP of the UAG is entered here
        server 10.117.43.230:443;
    }
        upstream ABSGservergroup {
        # Please make sure the correct IP of the UAG is entered here
        server 10.117.43.230:8443;
    }
 
    server {
        listen 443 ssl;
        # This is the internet to nginx traffic SSL termination related data
        ssl_certificate   /etc/nginx/keys/nginx.crt;
        ssl_certificate_key /etc/nginx/keys/nginx.key;
        ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers   ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
        ssl_prefer_server_ciphers  off;
        ssl_session_cache    shared:SSL:1m; # a 1mb cache can hold about 4000 sessions,
        ssl_session_timeout  24h;
        #keepalive_timeout 300; # up from 75 secs default
   
        # This is nginx traffic new SSL session between nginx and backend server
        proxy_ssl  on;
        proxy_pass UAGservergroup;
    }
    server {
        listen 8443 ssl;
        # This is the internet to nginx traffic SSL termination related data
        ssl_certificate   /etc/nginx/keys/nginx.crt;
        ssl_certificate_key /etc/nginx/keys/nginx.key;
        ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers   ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
        ssl_prefer_server_ciphers  off;
        ssl_session_cache    shared:SSL:1m; # a 1mb cache can hold about 4000 sessions,
        ssl_session_timeout  24h;
        #keepalive_timeout 300; # up from 75 secs default
   
        # This is nginx traffic new SSL session between nginx and backend server
        proxy_ssl  on;
        proxy_pass ABSGservergroup;
    }
}

Notice that both 443 and 8443 have been configured, ssl_certificate and key also located.

Edit /etc/nginx/nginx.conf, add “include /etc/nginx/endtoendencryption.conf;” to the end of http block.

http {
...
...
}
include /etc/nginx/endtoendencryption.conf;

Try “nginx -t” to validate the configuration and “service nginx reload” to reload it.

UAG configuration:

Try connect Nginx hostname from Horizon native client and launch VDI or application via Blast Protocol, issue should be resolved.