-* The following are limits for maximum number of API definitions linted per 4 hours:

- * Free tier: 10

- * Standard tier: 100

-> * API updates in API Management can take a few minutes to synchronize to your API center.

-| 1.2.3| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Gateway API v1.1, gRPC support, frontend mutual authentication, readiness probe fixes, custom health probe port and TLS mode |

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/end-to-end-ssl-with-backend-mtls/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- alb.networking.azure.io/alb-id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz

- {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz", "alb.networking.azure.io/alb-ingress-extension":"header-rewrite"},"name"

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- alb.networking.azure.io/alb-id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz

- {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- alb.networking.azure.io/alb-id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz

- {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- kubectl apply -f kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

-Congratulations, you have installed ALB Controller, deployed a backend application and used filtering to rewrite the client requested URL, prior to traffic being set to the target on Application Gateway for Containers.

-[  ](./media/how-to-url-rewrite-gateway-api/url-rewrite.png#lightbox)

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

- alb.networking.azure.io/alb-id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz

- {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"

- --version 1.2.3 \

- --version 1.2.3 \

-| alb-controller | 2/2 | 2 | 2 | 18d | alb-controller | mcr.microsoft.com/application-lb/images/alb-controller:**1.2.3** | app=alb-controller |

-| alb-controller-bootstrap | 1/1 | 1 | 1 | 18d | alb-controller-bootstrap | mcr.microsoft.com/application-lb/images/alb-controller-bootstrap:**1.2.3** | app=alb-controller-bootstrap |

-In this example, the ALB controller version is **1.2.3**.

-map.controls.add([

- new atlas.control.CompassControl(),

- new atlas.control.StyleControl()

-], {

- position: "top-right"

-});

-The following image shows a map with the zoom, compass, pitch, and style picker controls in the top-right corner of the map. Notice how they automatically stack. The order of the control objects in the script dictates the order in which they appear on the map. To change the order of the controls on the map, you can change their order in the array.

-> [ZoomControl]

-Azure NetApp Files volumes use a language type of [C.UTF-8](/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8), which covers many countries and languages including German, Cyrillic, Hebrew, and most Chinese/Japanese/Korean (CJK). Most common text characters in Unicode are 3 bytes or less. Special characters--such as emojis, musical symbols, and mathematical symbols--are often larger than 3 bytes. Some use [UTF-16 surrogate pair logic](/windows/win32/intl/surrogates-and-supplementary-characters).

->[!Note]

->Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.

->[!Note]

->Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.

- >Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.

- >

-### Additional limitations for Vaulted backup and Cross Region Restore (preview)

- - ignite-2023

-> [!NOTE]

-> Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.

-## Before you begin

-> [!NOTE]

-> Vaulted backup and Cross Region Restore for AKS using Azure Backup are currently in preview.

-## Restore in secondary region (preview)

-To restore the AKS cluster in the secondary region, [configure Geo redundancy and Cross Region Restore in the Backup vault](azure-kubernetes-service-cluster-backup.md#create-a-backup-vault), and then [trigger restore](tutorial-restore-aks-backups-across-regions.md#restore-in-secondary-region-preview).

- - ignite-2023

-In this quickstart, you configure backup for an Azure Kubernetes Service (AKS) cluster, and then use the Azure Backup configuration to back up specific items in the cluster.

-## Configure backup for an AKS cluster

-1. In the Azure portal, go to the AKS cluster that you want to back up.

- > [!NOTE]

- > Before you enable Trusted Access, enable the `TrustedAccessPreview` feature flag for the `Microsoft.ContainerServices` resource provider on the subscription.

-1. Select a backup policy, which defines the schedule for backups and their retention period. Then select **Next**.

-1. When validation is finished, if required roles aren't assigned to the vault in the snapshot resource group, an error appears.

- :::image type="content" source="./media/azure-kubernetes-service-cluster-backup/validation-error-permissions-not-assigned.png" alt-text="Screenshot that shows a validation error." lightbox="./media/azure-kubernetes-service-cluster-backup/validation-error-permissions-not-assigned.png":::

-# Quickstart: Configure backup for an Azure Kubernetes Service (AKS) cluster using Terraform

-This quickstart describes how to configure backup for an Azure Kubernetes Service (AKS) cluster using Terraform.

- - ignite-2023

-# Tutorial: Enable Vault Tier backups for AKS and restore across regions by using Azure Backup (preview)

-Azure Backup allows you to store AKS cluster backups in both **Operational Tier as snapshot** and **Vault Tier as blobs** (preview). This feature enables you to move snapshot-based AKS backups stored in Operational Tier to a Vault-standard Tier. You can use the backup policy, to define whether to store backups just in Operational Tier as snapshots or also protect them in Vault Tier along with Operational. Vaulted backups are stored offsite, which protects them from tenant compromise, malicious attacks, and ransomware threats. You can also retain the backup data for long term. Additionally, you can perform Cross Region Restore by configuring the Backup vault with storage redundancy set as global and Cross Region Restore property enabled. [Learn more](azure-kubernetes-service-backup-overview.md).

-## Configure Vault Tier backup (preview)

-## Restore in secondary region (preview)

-description: Get answers to frequently asked questions about connector deprecation.

-# Connector deprecation FAQ

-This article provides answers to frequently asked questions about connector deprecation.

-> [!IMPORTANT]

-> Azure Data Box now supports access tier assignment at the blob level. The steps contained within this tutorial reflect the updated data copy process and are specific to block blobs.

->

->For help with determining the appropriate access tier for your block blob data, refer to the [Determine appropriate access tiers for block blobs](#determine-appropriate-access-tiers-for-block-blobs) section. Follow the steps containined within the [Copy data to Data Box](#copy-data-to-data-box) section to copy your data to the appropriate access tier.

->

-> The information contained within this section applies to orders placed after April 1, 2024.

- * Be connected to a high-speed network. We strongly recommend that you have at least one 10-GbE connection. If a 10-GbE connection isn't available, a 1-GbE data link can be used but the copy speeds are impacted.

-Accessing Data Box Blob storage over HTTPS requires a TLS/SSL certificate for the device. The way in which this certificate is made available to the client application varies from application to application and across operating systems and distributions. Some applications can access the certificate after it's imported into the system's certificate store, while other applications don't make use of that mechanism.

-## Determine appropriate access tiers for block blobs

-> [!IMPORTANT]

-> The information contained within this section applies to orders placed after April 1^st, 2024.

-Azure Storage allows you to store block blob data in multiple access tiers within the same storage account. This ability allows data to be organized and stored more efficiently based on how often it's accessed. The following table contains information and recommendations about Azure Storage access tiers.

-| Tier | Recommendation | Best practice |

-||-||

-| Hot | Useful for online data accessed or modified frequently. This tier has the highest storage costs, but the lowest access costs. | Data in this tier should be in regular and active use. |

-| Cool | Useful for online data accessed or modified infrequently. This tier has lower storage costs and higher access costs than the hot tier. | Data in this tier should be stored for at least 30 days. |

-| Cold | Useful for online data accessed or modified rarely but still requiring fast retrieval. This tier has lower storage costs and higher access costs than the cool tier.| Data in this tier should be stored for a minimum of 90 days. |

-| Archive | Useful for offline data rarely accessed and having lower latency requirements. | Data in this tier should be stored for a minimum of 180 days. Data removed from the archive tier within 180 days is subject to an early deletion charge. |

-For more information about blob access tiers, see [Access tiers for blob data](../storage/blobs/access-tiers-overview.md). For more detailed best practices, see [Best practices for using blob access tiers](../storage/blobs/access-tiers-best-practices.md).

-You can transfer your block blob data to the appropriate access tier by copying it to the corresponding folder within Data Box. This process is discussed in greater detail within the [Copy data to Azure Data Box](#copy-data-to-data-box) section.

-After connecting to one or more Data Box shares, the next step is to copy data. Before you begin the data copy, consider the following limitations:

-4. A text box appears below the **Blob Containers** folder. Enter the name for your blob container. See the [Create the container and set permissions](../storage/blobs/storage-quickstart-blobs-dotnet.md) for information on rules and restrictions on naming blob containers.

-5. Press **Enter** when done to create the blob container, or **Esc** to cancel. After the blob container is successfully created, it's displayed under the **Blob Containers** folder for the selected storage account.

-> * Determining appropriate access tiers for block blobs

- If you're using an existing virtual network, you may need to modify the network configuration before you can install HDInsight. For more information, see the [add HDInsight to an existing virtual network](#existingvnet) section.

- HDInsight hosts multiple services, which use a variety of ports. Don't block traffic to these ports. For a list of ports to allow through virtual appliance firewalls, see the Security section.

- For more information, see the [Troubleshoot network security groups](../virtual-network/diagnose-network-traffic-filter-problem.md) document.

- For more information, see the [Troubleshoot routes](../virtual-network/diagnose-network-routing-problem.md) document.

-3. Create an HDInsight cluster and select the Azure Virtual Network during configuration. Use the steps in the following documents to understand the cluster creation process:

-You can connect to the cluster at `https://CLUSTERNAME.azurehdinsight.net`. This address uses a public IP, which may not be reachable if you have used NSGs to restrict incoming traffic from the internet. Additionally, when you deploy the cluster in a VNet you can access it using the private endpoint `https://CLUSTERNAME-int.azurehdinsight.net`. This endpoint resolves to a private IP inside the VNet for cluster access.

-When you create an HDInsight cluster, a load balancer is created as well. The type of this load balancer is at the [basic SKU level](../load-balancer/skus.md), which has certain constraints. One of these constraints is that if you have two virtual networks in different regions, you cannot connect to basic load balancers. See [virtual networks FAQ: constraints on global vnet peering](../virtual-network/virtual-networks-faq.md#what-are-the-constraints-related-to-global-virtual-network-peering-and-load-balancers), for more information.

-Another constraint is that the HDInsight load balancers should not be deleted or modified. **Any changes to the load balancer rules will get overwritten during certain maintenance events such as certificate renewals.** If the load balancers are modified and it affects the cluster functionality, you may need to recreate the cluster.

-description: Learn the resources available when you create an HDInsight cluster in an Azure Virtual Network.

-This article explains the resources that are present when you deploy an HDInsight cluster into a custom Azure Virtual Network. This information helps you to connect on-premises resources to your HDInsight cluster in Azure. For more information on Azure Virtual Networks, see [What is Azure Virtual Network?](../virtual-network/virtual-networks-overview.md).

-## Resource types in Azure HDInsight clusters

-These FQDNs will be of the form `<node-type-prefix><instance-number>-<abbreviated-clustername>.<unique-identifier>.cx.internal.cloudapp.net`.

-The `<node-type-prefix>` will be `hn` for headnodes, `wn` for worker nodes and `zn` for zookeeper nodes.

-|Load balancer | three | |

-|Public IP Addresses | two | |

-* For enterprise grade solutions, consider: [GlobalSign IoT Edge Enroll](https://www.globalsign.com/en/iot-edge-enroll) or [DigiCert IoT Device Manager](https://www.digicert.com/iot/iot-device-manager)

- vnet: aro-vnet

-**Storage target** | **Average source disk I/O** |**Average source disk data churn** | **Total source disk data churn per day**

-Premium P10 or P15 disk | 8 KB | 2 MB/s | 168 GB per disk

-Premium P10 or P15 disk | 16 KB | 4 MB/s | 336 GB per disk

-Premium P10 or P15 disk | 32 KB or greater | 8 MB/s | 672 GB per disk

-Premium P20 or P30 or P40 or P50 disk | 8 KB | 5 MB/s | 421 GB per disk

-Premium P20 or P30 or P40 or P50 disk | 16 KB or greater |20 MB/s | 1684 GB per disk

-There are two limits to consider: data churn per disk and data churn per virtual machine. Let's look at the Premium P20 disk in the following table for an example. For a single VM, Site Recovery can handle 5 MB/s of churn per disk with a maximum of five such disks. Site Recovery has a limit of 54 MB/s of total churn per VM.

-**Replication storage target** | **Average I/O size for source disk** |**Average data churn for source disk** | **Total data churn per day for source data disk**

-|||

-Standard storage | 8 KB | 2 MB/s | 168 GB per disk

-Premium P10 or P15 disk | 8 KB | 2 MB/s | 168 GB per disk

-Premium P10 or P15 disk | 16 KB | 4 MB/s | 336 GB per disk

-Premium P10 or P15 disk | 32 KB or greater | 8 MB/s | 672 GB per disk

-Premium P20 or P30 or P40 or P50 disk | 8 KB | 5 MB/s | 421 GB per disk

-Premium P20 or P30 or P40 or P50 disk | 16 KB or greater |20 MB/s | 1684 GB per disk

-|Target Disk Type|Avg I/O Size|Avg Churn Supported|

-|Standard or P10 or P15 |8 KB|2 MB/s|

-|Standard or P10 or P15|16 KB|4 MB/s|

-|Standard or P10 or P15|24 KB|6 MB/s|

-|Standard or P10 or P15|32 KB and later |10 MB/s|

-|P20|8 KB|10 MB/s|

-|P20 |16 KB|20 MB/s|

-|P20|24 KB and later|30 MB/s|

-|P30 and later|8 KB|20 MB/s|

-|P30 and later|16 KB|35 MB/s|

-|P30 and later|24 KB and later|50 MB/s|

-|Azure StorSimple 8000 Series Copy Utility documentation |Instructions for use of the Copy Utility. |

-|StorSimple archived documentation |Archived StorSimple articles from Microsoft technical documentation. |

-|Azure Synapse Apache Spark pool|[Query failure with a LIKE clause using Synapse Dedicated SQL Pool Connector in Spark 3.4 runtime](#query-failure-with-a-like-clause-using-synapse-dedicated-sql-pool-connector-in-spark-34-runtime)|Has Workaround|

-## Azure Synapse Analytics Apache Spark pool active known issues summary

-The following are known issues with the Synapse Spark.

-### Query failure with a LIKE clause using Synapse Dedicated SQL Pool Connector in Spark 3.4 runtime

-The open source Apache Spark 3.4 has introduced an [issue](https://issues.apache.org/jir), it can generate an invalid SQL query for Synapse SQL and the Synapse Spark notebook or batch job would throw an error similar to:

-`com.microsoft.spark.sqlanalytics.SQLAnalyticsConnectorException: com.microsoft.sqlserver.jdbc.SQLServerException: Parse error at line: 1, column: XXX: Incorrect syntax near ''%test%''`

-**Workaround**: The engineering team is currently aware of this behavior and working on a fix. If you encountered a similar error, please engage Microsoft Support Team for assistance and to provide a temporary workaround.

-

- - An existing [Azure load balancer](../load-balancer/load-balancer-outbound-connections.md) on the virtual network to which you're deploying the session hosts.

- | **Virtual machine location** | Select the Azure region where you want to deploy your session hosts. It must be the same region that contains your virtual network. Then select **Deploy to an Azure Extended Zone**. |

- | **Azure Extended Zones** | |

- | **Azure Extended Zone** | Select **Los Angeles**. |

- | **Place the session host(s) behind an existing load balancing solution?** | Select the box. This action shows options for selecting a load balancer and a back-end pool.|

- | **Select a load balancer** | Select an existing load balancer on the virtual network to which you're deploying the session hosts. |

- | **Select a backend pool** | Select a back-end pool on the load balancer in which you want to place the sessions hosts. |

- | **Availability options** | Select from [availability zones](/azure/reliability/availability-zones-overview), [availability set](/azure/virtual-machines/availability-set-overview), or **No infrastructure dependency required**. If you select **availability zones** or **availability set**, complete the extra parameters that appear. |

- | **Security type** | Select from **Standard**, [Trusted launch virtual machines](/azure/virtual-machines/trusted-launch), or [Confidential virtual machines](/azure/confidential-computing/confidential-vm-overview).<br /><br />- If you select **Trusted launch virtual machines**, options for **secure boot** and **vTPM** are automatically selected.<br /><br />- If you select **Confidential virtual machines**, options for **secure boot**, **vTPM**, and **integrity monitoring** are automatically selected. You can't opt out of vTPM when using a confidential VM. |

- - An existing [Azure load balancer](../load-balancer/load-balancer-outbound-connections.md) on the virtual network where you're deploying the session hosts.

- | **Virtual machine location** | Select the Azure region where you want to deploy your session hosts. This value must be the same region that contains your virtual network. Then select **Deploy to an Azure Extended Zone**. |

- | **Azure Extended Zones** | |

- | **Azure Extended Zone** | Select **Los Angeles**. |

- | **Place the session host(s) behind an existing load balancing solution?** | Select the box. This action shows options for selecting a load balancer and a back-end pool.|

- | **Select a load balancer** | Select an existing load balancer on the virtual network where you're deploying the session hosts. |

- | **Select a backend pool** | Select a back-end pool on the load balancer where you want to place the session hosts. |

- | **Availability options** | Select from [availability zones](/azure/reliability/availability-zones-overview), [availability set](/azure/virtual-machines/availability-set-overview), or **No infrastructure dependency required**. If you select **availability zones** or **availability set**, complete the extra parameters that appear. |

- | **Security type** | Select from **Standard**, [Trusted launch virtual machines](/azure/virtual-machines/trusted-launch), or [Confidential virtual machines](/azure/confidential-computing/confidential-vm-overview).<br /><br />- If you select **Trusted launch virtual machines**, options for **secure boot** and **vTPM** are automatically selected.<br /><br />- If you select **Confidential virtual machines**, options for **secure boot**, **vTPM**, and **integrity monitoring** are automatically selected. You can't opt out of vTPM when using a confidential VM. |

-description: Learn how to configure VPN Gateway server settings for P2S configurations - certificate authentication.

-This article helps you configure the necessary VPN Gateway point-to-site (P2S) server settings to let you securely connect individual clients running Windows, Linux, or macOS to an Azure virtual network (VNet). P2S VPN connections are useful when you want to connect to your VNet from a remote location, such as when you're telecommuting from home or a conference. You can also use P2S instead of a site-to-site (S2S) VPN when you have only a few clients that need to connect to a virtual network (VNet).

-The steps in this article create a P2S configuration that uses **certificate authentication** and the Azure portal. To create this configuration using the Azure PowerShell, see the [Configure P2S - Certificate - PowerShell](vpn-gateway-howto-point-to-site-rm-ps.md) article. For RADIUS authentication, see the [P2S RADIUS](point-to-site-how-to-radius-ps.md) article. For Microsoft Entra authentication, see the [P2S Microsoft Entra ID](openvpn-azure-ad-tenant.md) article.

-Verify that you have an Azure subscription. If you don't already have an Azure subscription, you can activate your [MSDN subscriber benefits](https://azure.microsoft.com/pricing/member-offers/msdn-benefits-details) or sign up for a [free account](https://azure.microsoft.com/pricing/free-trial).

-### <a name="example"></a>Example values

-You can use the following values to create a test environment, or refer to these values to better understand the examples in this article:

-**VNet**

-* **VNet Name:** VNet1

-* **Address space:** 10.1.0.0/16<br>For this example, we use only one address space. You can have more than one address space for your VNet.

-* **Subnet name:** FrontEnd

-* **Subnet address range:** 10.1.0.0/24

-* **Subscription:** If you have more than one subscription, verify that you're using the correct one.

-* **Resource Group:** TestRG1

-* **Location:** East US

-**Virtual network gateway**

-* **Virtual network gateway name:** VNet1GW

-* **Gateway type:** VPN

-* **VPN type:** Route-based (required for P2S)

-* **SKU:** VpnGw2

-* **Generation:** Generation2

-* **Gateway subnet address range:** 10.1.255.0/27

-* **Public IP address name:** VNet1GWpip

-* **Public IP address name 2:** VNet1GWpip2 - for active-active mode gateways.

-**Connection type and client address pool**

-* **Connection type:** Point-to-site

-* **Client address pool:** 172.16.201.0/24<br>VPN clients that connect to the VNet using this point-to-site connection receive an IP address from the client address pool.

-## <a name="createvnet"></a>Create a VNet

-In this section, you create a VNet. Refer to the [Example values](#example) section for the suggested values to use for this configuration.

-## Create a gateway subnet

-The virtual network gateway requires a specific subnet named **GatewaySubnet**. The gateway subnet is part of the IP address range for your virtual network and contains the IP addresses that the virtual network gateway resources and services use. Specify a gateway subnet that's /27 or larger.

-## <a name="creategw"></a>Create the VPN gateway

-In this step, you create the virtual network gateway for your VNet. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU.

-> [!NOTE]

-> The Basic gateway SKU does not support IKEv2 or RADIUS authentication. If you plan on having Mac clients connect to your VNet, do not use the Basic SKU.

-You can see the deployment status on the **Overview** page for your gateway. After the gateway is created, you can view the IP address that has been assigned to it by looking at the VNet in the portal. The gateway appears as a connected device.

-Certificates are used by Azure to authenticate clients connecting to a VNet over a point-to-site VPN connection. Once you obtain a root certificate, you [upload](#uploadfile) the public key information to Azure. The root certificate is then considered 'trusted' by Azure for connection over P2S to the VNet.

-You also generate client certificates from the trusted root certificate, and then install them on each client computer. The client certificate is used to authenticate the client when it initiates a connection to the VNet.

-## <a name="addresspool"></a>Add the address pool

-The **Point-to-site configuration** page contains the configuration information that's needed for the P2S VPN. Once all the P2S settings have been configured and the gateway has been updated, the Point-to-site configuration page is used to view or change P2S VPN settings.

-1. Go to the gateway you created in the previous section.

-1. In the left pane, select **Point-to-site configuration**.

-1. Click **Configure now** to open the configuration page.

-The client address pool is a range of private IP addresses that you specify. The clients that connect over a point-to-site VPN dynamically receive an IP address from this range. Use a private IP address range that doesn't overlap with the on-premises location that you connect from, or the VNet that you want to connect to. If you configure multiple protocols and SSTP is one of the protocols, then the configured address pool is split between the configured protocols equally.

- :::image type="content" source="./media/vpn-gateway-howto-point-to-site-resource-manager-portal/configuration-address-pool.png" alt-text="Screenshot of Point-to-site configuration page - address pool." lightbox="./media/vpn-gateway-howto-point-to-site-resource-manager-portal/configuration-address-pool.png":::

-1. On the **Point-to-site configuration** page, in the **Address pool** box, add the private IP address range that you want to use. VPN clients dynamically receive an IP address from the range that you specify. The minimum subnet mask is 29 bit for active/passive and 28 bit for active/active configuration.

-If your VPN gateway is configured with an availability zone SKU (AZ) and is in active-active mode, point-to-site VPN configurations require three public IP addresses. You can use the example value **VNet1GWpip3**.

-## <a name="type"></a>Specify tunnel and authentication type

->

-In this section, you specify the tunnel type and the authentication type. These settings can become complex, depending on the tunnel type you require and the VPN client software that will be used to make the connection from the user's operating system. The steps in this article walk you through basic configuration settings and choices.

-You can select options that contain multiple tunnel types from the dropdown - such as *IKEv2 and OpenVPN(SSL)* or *IKEv2 and SSTP (SSL)*, however, only certain combinations of tunnel types and authentication types are supported. For example, Microsoft Entra authentication can only be used when you select *OpenVPN (SSL)* from the tunnel type dropdown, and not *IKEv2 and OpenVPN(SSL)*.

-Additionally, the tunnel type and the authentication type correspond to the VPN client software that can be used to connect to Azure. For example, one VPN client software application might be only able to connect via IKEv2, while another can only connect via OpenVPN. And some client software, while it supports a certain tunnel type, might not support the authentication type you choose.

-As you can tell, planning the tunnel type and authentication type is important when you have various VPN clients connecting from different operating systems. Consider the following criteria when you choose your tunnel type in combination with **Azure certificate** authentication. Other authentication types have different considerations.

-* **Windows**:

- * Windows computers connecting via the native VPN client already installed in the operating system try IKEv2 first and, if that doesn't connect, they fall back to SSTP (if you selected both IKEv2 and SSTP from the tunnel type dropdown).

- * If you select the OpenVPN tunnel type, you can connect using an OpenVPN Client or the Azure VPN Client.

- * The Azure VPN Client can support [optional configuration settings](azure-vpn-client-optional-configurations.md) such as custom routes and forced tunneling.

-* **macOS and iOS**:

- * The native VPN client for iOS and macOS can only use the IKEv2 tunnel type to connect to Azure.

- * The Azure VPN Client isn't supported for certificate authentication at this time, even if you select the OpenVPN tunnel type.

- * If you want to use the OpenVPN tunnel type with certificate authentication, you can use an OpenVPN client.

- * For macOS, you can use the Azure VPN Client with the OpenVPN tunnel type and Microsoft Entra ID authentication (not certificate authentication).

-* **Linux**:

- * The Azure VPN Client for Linux supports the OpenVPN tunnel type.

- * The strongSwan client on Android and Linux can use only the IKEv2 tunnel type to connect.

-### Tunnel and authentication type

-1. For **Authentication type**, select the authentication type that you want to use. For this exercise, from the dropdown, select **Azure certificate**. If you're interested in other authentication types, see the articles for [Microsoft Entra ID](openvpn-azure-ad-tenant.md) and [RADIUS](point-to-site-how-to-radius-ps.md).

-## <a name="publicip3"></a>Additional IP address

-If you have an active-active mode gateway that uses an availability zone SKU (AZ SKU), you need a third public IP address. If this setting doesn't apply to your gateway, you don't need to add an additional IP address.

-In this section, you upload public root certificate data to Azure. Once the public certificate data is uploaded, Azure can use it to authenticate clients that have installed a client certificate generated from the trusted root certificate.

-All the necessary configuration settings for the VPN clients are contained in a VPN client profile configuration zip file. VPN client profile configuration files are specific to the P2S VPN gateway configuration for the VNet. If there are any changes to the P2S VPN configuration after you generate the files, such as changes to the VPN protocol type or authentication type, you need to generate new VPN client profile configuration files and apply the new configuration to all of the VPN clients that you want to connect. For more information about P2S connections, see [About point-to-site VPN](point-to-site-about.md).

-### PowerShell

-For steps to configure your VPN clients and connect to Azure, see the following articles:

-## <a name="verify"></a>Verify your connection

-These instructions apply to Windows clients.

-1. To verify that your VPN connection is active, open an elevated command prompt, and run *ipconfig/all*.

-1. View the results. Notice that the IP address you received is one of the addresses within the point-to-site VPN Client Address Pool that you specified in your configuration. The results are similar to this example:

- ```

- PPP adapter VNet1:

- Connection-specific DNS Suffix .:

- Description.....................: VNet1

- Physical Address................:

- DHCP Enabled....................: No

- Autoconfiguration Enabled.......: Yes

- IPv4 Address....................: 172.16.201.3(Preferred)

- Subnet Mask.....................: 255.255.255.255

- Default Gateway.................:

- NetBIOS over Tcpip..............: Enabled

- ```

-## <a name="connectVM"></a>Connect to a virtual machine

-These instructions apply to Windows clients.

-* Verify that the VPN client configuration package was generated after the DNS server IP addresses were specified for the VNet. If you updated the DNS server IP addresses, generate and install a new VPN client configuration package.

-* Use 'ipconfig' to check the IPv4 address assigned to the Ethernet adapter on the computer from which you're connecting. If the IP address is within the address range of the VNet that you're connecting to, or within the address range of your VPNClientAddressPool, this is referred to as an overlapping address space. When your address space overlaps in this way, the network traffic doesn't reach Azure, it stays on the local network.

-You can add and remove trusted root certificates from Azure. When you remove a root certificate, clients that have a certificate generated from that root won't be able to authenticate, and thus won't be able to connect. If you want a client to authenticate and connect, you need to install a new client certificate generated from a root certificate that is trusted (uploaded) to Azure.

-Once your connection is complete, you can add virtual machines to your VNets. For more information, see [Virtual Machines](../index.yml). To understand more about networking and virtual machines, see [Azure and Linux VM network overview](../virtual-network/network-overview.md).