Known Issues

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

Not all new use-cases are supported in NGINX Plus R30 (ID-3952)

We currently provide only partial support for the use-cases outlined in the released NGINX Plus R30. You can follow the updates to the supported use-cases by visiting the Changelog. For a comprehensive list of currently allowed directives, please see the Configuration Directives List.

Not all new use-cases are supported in NGINX Plus R29 (ID-3176)

We currently provide only partial support for the use-cases outlined in the released NGINX Plus R29. You can follow the updates to the supported use-cases by visiting the Changelog. For a comprehensive list of currently allowed directives, please see the Configuration Directives List.

Terraform shows an error while trying to manage configuration of a fresh deployment (ID-891)

If you use Terraform to create a new NGINXaaS deployment and manage its configuration, you will see the following import error for the NGINXaaS Configuration resource:

azurerm_nginx_configuration.example: Creating...
╷
│ Error: A resource with the ID "/subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/group1/providers/Nginx.NginxPlus/nginxDeployments/dep1/configurations/default" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_nginx_configuration" for more information.
│
│   with azurerm_nginx_configuration.example,
│   on main.tf line 44, in resource "azurerm_nginx_configuration" "example":
│   44: resource "azurerm_nginx_configuration" "example" {
│
│ A resource with the ID
│ "/subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/group1/providers/Nginx.NginxPlus/nginxDeployments/dep1/configurations/default"
│ already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for
│ "azurerm_nginx_configuration" for more information.

The cause for the error is that a new deployment has a default configuration associated with it. When you run Terraform to create a deployment and its configuration, Terraform does not know about the default configuration. When it starts creating the configuration resource, it finds that the configuration resource already exists and generates an error asking the user to import the configuration before moving forward.

Workaround:

Import the configuration resource and re-run Terraform:

terraform import azurerm_nginx_configuration.example /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/group1/providers/Nginx.NginxPlus/nginxDeployments/dep1/configurations/default

terraform plan

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

“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:

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 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 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.

Deployment locked when updating mutliple certificates at once. (ID-767)

Attaching multiple certificates to a deployment quickly will result in a deployment conflict and error with a “409” status code. Certificates are a sub-resource of the deployment, and a user cannot attach multiple certificates to a deployment simultaneously. This issue is more likely to occur when attempting to configure multiple certificates using client tools such as Terraform and ARM templates.

Workaround: If you want to add multiple certificates to a deployment, configure resource dependencies between the certificate resources, which will cause them to be added to the deployment one at a time.

Terraform:

Use depends_on to add a dependency between certificate resources:

resource "azurerm_nginx_certificate" "cert1" {
  name                     = "examplecert"
  nginx_deployment_id      = azurerm_nginx_deployment.test.id
  key_virtual_path         = "/src/cert/soservermekey.key"
  certificate_virtual_path = "/src/cert/server.cert"
  key_vault_secret_id      = azurerm_key_vault_certificate.test.secret_id
}

resource "azurerm_nginx_certificate" "cert2" {
  name                     = "examplecert"
  nginx_deployment_id      = azurerm_nginx_deployment.test.id
  key_virtual_path         = "/src/cert/soservermekey.key"
  certificate_virtual_path = "/src/cert/server.cert"
  key_vault_secret_id      = azurerm_key_vault_certificate.test.secret_id

  depends_on               = [azurerm_nginx_certificate.cert1]
}

ARM Template

Use dependsOn to add a dependency between certificate resources:

{
    "type": "NGINX.NGINXPLUS/nginxDeployments/certificates",
    "apiVersion": "2021-05-01-preview",
    "name": "[concat(parameters('nginxDeploymentName'), '/', 'cert1')]",
    "properties": {
        "certificateVirtualPath": "[parameters('certificateVirtualPath')]",
        "keyVirtualPath": "[parameters('keyVirtualPath')]",
        "keyVaultSecretId": "[parameters('keyVaultSecretId')]"
     }
}

{
    "type": "NGINX.NGINXPLUS/nginxDeployments/certificates",
    "apiVersion": "2021-05-01-preview",
    "name": "[concat(parameters('nginxDeploymentName'), '/', 'cert2')]",
    "properties": {
        "certificateVirtualPath": "[parameters('certificateVirtualPath')]",
        "keyVirtualPath": "[parameters('keyVirtualPath')]",
        "keyVaultSecretId": "[parameters('keyVaultSecretId')]"
     }
    "dependsOn": ["cert1"]
}

Bicep Template