On November 5, 2019, the ProxySG software began to receive failed requests from the AWS metadata server. Existing instances that are configured and running are not impacted by the failed requests. For new instances, the initial boot process fails with the following error indicators in the AWS web console:
On November 5, 2019, AWS updated the metadata service (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) on their EC2 platform. This change affected the ProxySG virtual appliances (VAs) by making a previously accepted request string no longer functional.
On the first boot, the ProxySG VA queries the AWS metadata service to determine what processes need to automatically occur, such as:
The fix to the issue was introduced in SGOS 220.127.116.11. Obtain this version of SGOS from the AWS Marketplace and use it to deploy a new instance in the AWS Marketplace. Older AMIs that were manually created should not be used, nor should older AMIs from the AWS Marketplace. For instructions on deploying your ProxySG VA, see https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/proxysg/7-3/aws-marketplace-about-proxysg.html.
This issue only affects newly created VAs on AWS Marketplace. This issue does not impact any physical appliances or VAs deployed on any other platform.
No. Instances that are currently running and have had their initial configuration wizard completed (either via the Mini ICW or userdata) no longer require access to the metadata server to properly operate. These instances can continue to operate as is, and can be updated using the load upgrade mechanism. However, if you want to erase configuration via the
restore defaults command, or create a new VA in AWS Marketplace using an older AMI, your VA will be affected because it will need to contact the metadata server.
Symantec recommends that you upgrade existing instances to avoid future issues that could be triggered by issuing a
restore defaults command; however, if your existing instances are running, configured, and working you are not required to upgrade. Any new instances that are created must be created using an AMI that has the fix for this issue (SGOS 18.104.22.168 and later).