You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-wan/how-to-network-virtual-appliance-inbound.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Learn how to use Destination NAT with a Network Virtual Appliance i
4
4
author: wellee
5
5
ms.service: azure-virtual-wan
6
6
ms.topic: how-to
7
-
ms.date: 01/04/2023
7
+
ms.date: 10/25/2024
8
8
ms.author: cherylmc
9
9
# Customer intent: As someone with a networking background, I want to create a Network Virtual Appliance (NVA) in my Virtual WAN hub and leverage destination NAT.
10
10
---
@@ -41,16 +41,16 @@ The following configurations are performed:
The list below corresponds to the diagram above and describes the packet flow for the inbound connection:
46
+
The following list corresponds to the diagram above and describes the packet flow for the inbound connection:
47
47
48
48
1. The user initiates a connection with one of the Public IPs used for DNAT associated to the NVA.
49
49
1. Azure load balances the connection request to one of the Firewall NVA instances. Traffic is sent to the external/untrusted interface of the NVA.
50
50
1. NVA inspects the traffic and translates the packet based on rule configuration. In this case, the NVA is configured to NAT and forward inbound traffic to 10.60.0.4:443. The source of the packet is also translated to the private IP (IP of trusted/internal interface) of the chosen Firewall instance to ensure flow symmetry. The NVA forwards the packet and Virtual WAN routes the packet to the final destination.
The list below corresponds to the diagram above and describes the packet flow for the outbound response:
56
56
@@ -66,15 +66,15 @@ The list below corresponds to the diagram above and describes the packet flow fo
66
66
* Destination NAT Public IPs must be from the same region as the NVA resource. For example, if the NVA is deployed in the East US region, the public IP must also be from the East US region.
67
67
* Destination NAT Public IPs can't be in use by another Azure resource. For example, you can't use an IP address in use by a Virtual Machine network interface IP Configuration or a Standard Load Balancer front-end configuration.
68
68
* Public IPs must be from IPv4 address spaces. Virtual WAN doesn't support IPv6 addresses.
69
-
* Public IPs must be deployed with Standard SKU. Basic SKU Public IPs are not supported.
69
+
* Public IPs must be deployed with Standard SKU. Basic SKU Public IPs aren't supported.
70
70
* Destination NAT is only supported on new NVA deployments that are created with at least one Destination NAT Public IP. Existing NVA deployments or NVA deployments that didn't have a Destination NAT Public IP associated at NVA creation time aren't eligible to use Destination NAT.
71
71
* Programming Azure infrastructure components to support DNAT scenarios is done automatically by NVA orchestration software when a DNAT rule is created. Therefore, you can't program NVA rules through Azure portal. However, you can view the inbound security rules associated to each internet inbound Public IP.
72
72
* DNAT traffic in Virtual WAN can only be routed to connections to the same hub as the NVA. Inter-hub traffic patterns with DNAT aren't supported.
73
73
74
74
### Considerations
75
75
76
76
* Inbound Traffic is automatically load-balanced across all healthy instances of the Network Virtual Appliance.
77
-
* In most cases, NVAs must perform source-NAT to the Firewall private IP in addition to destination-NAT to ensure flow symmetry. Certain NVA types may not require source-NAT. Contact your NVA provider for best practices around source-NAT.
77
+
* In most cases, NVAs must perform source-NAT to the Firewall private IP in addition to destination-NAT to ensure flow symmetry. Certain NVA types might not require source-NAT. Contact your NVA provider for best practices around source-NAT.
78
78
* Timeout for idle flows is automatically set to 4 minutes.
79
79
* You can assign individual IP address resources generated from an IP address prefix to the NVA as internet inbound IPs. Assign each IP address from the prefix individually.
80
80
@@ -111,7 +111,7 @@ The following section describes how to manage NVA configurations related to inte
111
111
> IP addresses can only be removed if there are no rules associated to that IP is 0. Remove all rules associated to the IP by removing DNAT rules assigned to that IP from your NVA management software.
112
112
113
113
Select the IP you want to remove from the grid and click **Delete**.
114
-
:::image type="content" source="./media/virtual-wan-network-virtual-appliance-inbound/delete-ip.png"alt-text="Screenshot showing how to delete IP from NVA."lightbox="./media/virtual-wan-network-virtual-appliance-inbound/delete-ip.png":::
114
+
:::image type="content" source="./media/virtual-wan-network-virtual-appliance-inbound/delete-ip.png"alt-text="Screenshot showing how to delete IP from NVA."lightbox="./media/virtual-wan-network-virtual-appliance-inbound/delete-ip.png":::
115
115
116
116
## Programming DNAT Rules
117
117
@@ -131,7 +131,7 @@ The following section describes some common troubleshooting scenarios.
131
131
***Option to associate IP to NVA resource not available through Azure portal** : Only NVAs that are created with DNAT/Internet Inbound IPs at deployment time are eligible to use DNAT capabilities. Delete and re-create the NVA with an Internet Inbound IP assigned at deployment time.
132
132
***IP address not showing up in dropdown Azure portal**: Public IPs only show up in the dropdown menu if the IP address is IPv4, in the same region as the NVA and isn't in use/assigned to another Azure resource. Ensure the IP address you're trying to use meets the above requirements, or create a new IP address.
133
133
***Can't delete/disassociate Public IP from NVA**: Only IP addresses that have no rules associated with them can be deleted. Use the NVA orchestration software to remove any DNAT rules associated to that IP address.
134
-
***NVA provisioning state not succeeded**: If there are on-going operations on the NVA or if the provisioning status of the NVA is **not successful**, IP address association fails. Wait for any existing operations to terminate.
134
+
***NVA provisioning state not succeeded**: If there are ongoing operations on the NVA or if the provisioning status of the NVA is **not successful**, IP address association fails. Wait for any existing operations to terminate.
135
135
136
136
### <aname="healthprobeconfigs"></a> Load balancer health probes
Copy file name to clipboardExpand all lines: articles/virtual-wan/migrate-from-hub-spoke-topology.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Learn how to migrate from an existing customer-managed hub-and-spok
4
4
author: cherylmc
5
5
ms.service: azure-virtual-wan
6
6
ms.topic: conceptual
7
-
ms.date: 10/13/2022
7
+
ms.date: 10/25/2024
8
8
ms.author: cherylmc
9
9
10
10
---
@@ -24,7 +24,7 @@ This article shows how to migrate an existing customer-managed hub-and-spoke env
24
24
25
25
## Scenario
26
26
27
-
Contoso is a global financial organization with offices in both Europe and Asia. They are planning to move their existing applications from an on-premises data center in to Azure and have built out a foundation design based on the customer-managed hub-and-spoke architecture, including regional hub virtual networks for hybrid connectivity. As part of the move to cloud-based technologies, the network team has been tasked with ensuring that their connectivity is optimized for the business moving forward.
27
+
Contoso is a global financial organization with offices in both Europe and Asia. They're planning to move their existing applications from an on-premises data center in to Azure and have built out a foundation design based on the customer-managed hub-and-spoke architecture, including regional hub virtual networks for hybrid connectivity. As part of the move to cloud-based technologies, the network team has been tasked with ensuring that their connectivity is optimized for the business moving forward.
28
28
29
29
The following figure shows a high-level view of the existing global network including connectivity to multiple Azure regions.
Copy file name to clipboardExpand all lines: articles/virtual-wan/point-to-site-concepts.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ description: Learn about Virtual WAN User VPN P2S VPN concepts.
5
5
author: cherylmc
6
6
ms.service: azure-virtual-wan
7
7
ms.topic: how-to
8
-
ms.date: 12/05/2022
8
+
ms.date: 10/25/2024
9
9
ms.author: cherylmc
10
10
11
11
---
@@ -30,7 +30,7 @@ The following concepts are related to server configurations that use certificate
30
30
31
31
| Concept | Description | Notes|
32
32
|--| --|--|
33
-
| Root certificate name | Name used by Azure to identify customer root certificates. | Can be configured to be any name. You may have multiple root certificates. |
33
+
| Root certificate name | Name used by Azure to identify customer root certificates. | Can be configured to be any name. You can have multiple root certificates. |
34
34
| Public certificate data | Root certificate(s) from which client certificates are issued.| Input the string corresponding to the root certificate public data. For an example for how to get root certificate public data, see the step 8 in the following document about [generating certificates](certificates-point-to-site.md). |
35
35
| Revoked certificate | Name used by Azure to identify certificates to be revoked. | Can be configured to be any name.|
36
36
| Revoked certificate thumbprint| Thumbprint of the end user certificate(s) that shouldn't be able to connect to the gateway. | The input for this parameter is one or more certificate thumbprints. Every user certificate must be revoked individually. Revoking an intermediate certificate or a root certificate won't automatically revoke all children certificates. |
@@ -45,7 +45,7 @@ If a P2S VPN gateway is configured to use RADIUS-based authentication, the P2S V
45
45
| Primary server IP address|Private IP address of RADIUS server| This IP must be a private IP reachable by the Virtual Hub. Make sure the connection hosting the RADIUS server is propagating to the defaultRouteTable of the hub with the gateway.|
46
46
| Secondary server secret| Server secret configured on the second RADIUS server that is used for encryption by RADIUS protocol.| Any provided shared secret string.|
47
47
| Secondary server IP address|The private IP address of the RADIUS server| This IP must be a private IP reachable by the virtual hub. Make sure the connection hosting the RADIUS server is propagating to the defaultRouteTable of the hub with the gateway.|
48
-
|RADIUS server root certificate | RADIUS server root certificate public data.| This field is optional. Input the string(s) corresponding to the RADIUS root certificate public data. You may input multiple root certificates. All client certificates presented for authentication must be issued from the specified root certificates. For an example for how to get certificate public data, see the step 8 in the following document about [generating certificates](certificates-point-to-site.md).|
48
+
|RADIUS server root certificate | RADIUS server root certificate public data.| This field is optional. Input the string(s) corresponding to the RADIUS root certificate public data. You can input multiple root certificates. All client certificates presented for authentication must be issued from the specified root certificates. For an example for how to get certificate public data, see the step 8 in the following document about [generating certificates](certificates-point-to-site.md).|
49
49
|Revoked client certificates |Thumbprint(s) of revoked RADIUS client certificates. Clients presenting revoked certificates won't be able to connect. |This field is optional. Every user certificate must be revoked individually. Revoking an intermediate certificate or a root certificate won't automatically revoke all children certificates.|
@@ -82,7 +82,7 @@ The server configuration contains the definitions of groups and the groups are t
82
82
|--| --|--|
83
83
|User group / policy group|A user Group or policy group is a logical representation of a group of users that should be assigned IP addresses from the same address pool.| For more information, see [about user groups.](user-groups-about.md)|
84
84
|Default group|When users try to connect to a gateway using the user group feature, users who don't match any group assigned to the gateway are automatically considered to be part of the default group and assigned an IP address associated to that group. |Each group in a server configuration can be specified as a default group or non-default group and this setting **cannot** be changed after the group has been created. Exactly one default group can be assigned to each P2S VPN gateway, even if the assigned server configuration has multiple default groups.|
85
-
|Group priority|When multiple groups are assigned to a gateway a connecting user may present credentials that match multiple groups. Virtual WAN processes groups assigned to a gateway in increasing order of priority.|Priorities are positive integers and groups with lower numerical priorities are processed first. Every group must have a distinct priority.|
85
+
|Group priority|When multiple groups are assigned to a gateway a connecting user might present credentials that match multiple groups. Virtual WAN processes groups assigned to a gateway in increasing order of priority.|Priorities are positive integers and groups with lower numerical priorities are processed first. Every group must have a distinct priority.|
86
86
|Group settings/members| User groups consist of members. Members don't correspond to individual users but rather define the criteria/match condition(s) used to determine which group a connecting user is a part of. Once a group is assigned to a gateway, a connecting user whose credentials match the criteria specified for one of the group's members, is considered to be part of that group and can be assigned an appropriate IP address. |For a full list of available criteria, see [available group settings](user-groups-about.md).|
87
87
88
88
## Gateway configuration concepts
@@ -114,8 +114,8 @@ There can be one or more connection configurations on a P2S VPN gateway. Each co
114
114
|--|--|--|
115
115
| Configuration Name | Name for a P2S VPN configuration | Any name can be provided. You can have more than one connection configuration on a gateway if you're leveraging the user groups/multi-pool feature. If you aren't using this feature, there can only be one configuration per gateway.|
116
116
| User Groups | User groups that correspond to a configuration | Any user group(s) referenced in the VPN Server configuration. This parameter is optional. For more information, see [about user groups](user-groups-about.md).|
117
-
| Address Pools|Address pools are private IP addresses that connecting users are assigned.|Address pools can be specified as any CIDR block that doesn't overlap with any Virtual Hub address spaces, IP addresses used in Virtual Networks connected to Virtual WAN or addresses advertised from on-premises. Depending on the scale unit specified on the gateway, you may need more than one CIDR block. For more information, see [about address pools](about-client-address-pools.md).|
118
-
|Routing configuration|Every connection to Virtual Hub has a routing configuration, which defines which route table the connection is associated to and which route tables the route table propagates to. |All branch connections to the same hub (ExpressRoute, VPN, NVA) must associate to the defaultRouteTable and propagate to the same set of route tables. Having different propagations for branches connections may result in unexpected routing behaviors, as Virtual WAN will choose the routing configuration for one branch and apply it to all branches and therefore routes learned from on-premises.|
117
+
| Address Pools|Address pools are private IP addresses that connecting users are assigned.|Address pools can be specified as any CIDR block that doesn't overlap with any Virtual Hub address spaces, IP addresses used in Virtual Networks connected to Virtual WAN or addresses advertised from on-premises. Depending on the scale unit specified on the gateway, you might need more than one CIDR block. For more information, see [about address pools](about-client-address-pools.md).|
118
+
|Routing configuration|Every connection to Virtual Hub has a routing configuration, which defines which route table the connection is associated to and which route tables the route table propagates to. |All branch connections to the same hub (ExpressRoute, VPN, NVA) must associate to the defaultRouteTable and propagate to the same set of route tables. Having different propagations for branches connections might result in unexpected routing behaviors, as Virtual WAN will choose the routing configuration for one branch and apply it to all branches and therefore routes learned from on-premises.|
0 commit comments