Known Issues

List of known issues in the latest release of NGINX as a Service for Azure

Terraform errors using package_data (ID-2752)

Specifying a configuration via a tar.gz file and the package_data directive fails.

│ Error: Insufficient config_file blocks
│
│   on main.tf line 105, in resource "azurerm_nginx_configuration" "example":
│  105: resource "azurerm_nginx_configuration" "example" {
│
│ At least 1 "config_file" blocks are required.

Workaround: Extract the files from your tar.gz and use the config_file directive instead of package_data

NGINXaaS cannot serve static files with error page. (ID-2701)

Specifying a static file with the error_page directive will result in an error.

Workaround: See error_page’s documentation for more options on handling errors.

“Selected subscription doesn’t have enough available address space that meets all the constraints of the default virtual network specified.” error while configuring deployment network configuration. (ID-2512)

When creating a new deployment, the following error might appear while configuring the network configuration for the deployment:

Subnet Error

The error is caused by Azure scanning the user subscription for all Virtual Networks (VNETs) to determine if there is any non-overlapping IP space available to create a new VNET for the deployment, as the user might want to peer the deployment VNET with an existing VNET in the subscription.

Note:
VNET peering requires that the networks being peered have non-overlapping IP space.

Workaround: The error is a warning and can be safely ignored if you do not intend to peer the deployment VNET with existing VNETs in the subscription. You can create a new VNET/subnet from the Networking tab and proceed with the deployment creation, and the error will go away from the portal screen automatically.

Deployment responsiveness takes approximately 5-10 seconds. (ID-872)

When creating a new deployment or exposing a new port for traffic, there might be a lag time of 5-10 seconds, during which the Azure Load Balancer does not recognize the new ports, thus preventing making new connections to the NGINX deployment.

Workaround: Wait 5-10 seconds to make requests, or make multiple requests to the instance with low connect timeout times after creating a new deployment or exposing a new port to the deployment (80/443) for the first 10 seconds after the deployment reaches the Completed state.

NGINX config allows only files mapped to an include directive. (ID-1335)

Files not listed with an include directive get an API 400 error response. NGINX configuration files are accepted if their filename matches an include directive using a glob pattern/mask (e.g. include conf.d/*).

NGINXaaS for Azure charges do not render correctly in the Azure Portal cost center. (ID-1660)

NGINXaaS for Azure resources appear with a random suffix, and clicking the link does not lead to the NGINXaaS for Azure resource overview page. The charge details show “Unassigned” for all fields, but the charge amount is accurate.

Configuration update will not succeed with a failed certificate. (ID-1545)

If a configuration update request uses a certificate that is in failed provisioningState, the configuration update is rejected.

Workaround: Update the referenced certificate before updating the configuration. Make sure the certificate provisioning is successful and retry the configuration update.

Known networking limitations (ID-625)

  • NGINXaaS deployments cannot access Private Endpoints behind network security groups for private links. Attempts to do so will fail silently.
  • NGINXaaS deployments cannot access Private Endpoints in a globally peered VNET. Attempts to do so will fail silently.
  • The resource group which contains the public IP resource attached to NGINXaaS deployment cannot be moved across subscriptions. Attempts to do so will result in a validation error.
  • Creating an NGINXaaS deployment in a dual-stack subnet is not supported. Attempts to do so will result in a validation error.
  • NGINXaaS deployments cannot be created with an IPv6 Public IP address. Attempts to do so will result in a validation error.
  • Network security group (NSG) flow logs will not be available for IP traffic flowing through an NGINXaaS deployment attached to a customer delegated subnet. Flow logs for other resources on the same subnet will be available as normal.

Deployment cannot use existing resource group as managed resource group. (ID-631)

NGINXaaS cannot use an existing resource group as a managed resource group. An attempt to specify the managed_resource_group field via the client tools will result in a deployment failure and you will not be able to delete the deployment.

Workaround: Do not create a deployment with managed_resource_group field set to an existing resource group; let the service handle the lifecycle of the managed resource group instead.