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/app-service/app-service-hybrid-connections.md
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ ms.workload: na
13
13
ms.tgt_pltfrm: na
14
14
ms.devlang: na
15
15
ms.topic: article
16
-
ms.date: 07/26/2018
16
+
ms.date: 06/06/2019
17
17
ms.author: ccompy
18
18
ms.custom: seodec18
19
19
@@ -39,7 +39,6 @@ When your app makes a DNS request that matches a configured Hybrid Connection en
39
39
> This means that you should try to always use a DNS name for your Hybrid Connection. Some client software does not do a DNS lookup if the endpoint uses an IP address instead.
40
40
>
41
41
42
-
43
42
### App Service Hybrid Connection benefits ###
44
43
45
44
There are a number of benefits to the Hybrid Connections capability, including:
@@ -137,7 +136,7 @@ To add one or more Hybrid Connections to your HCM:
137
136
2. Select **Configure another Hybrid Connection**.
138
137
![Screenshot of Configure New Hybrid Connections][8]
139
138
140
-
1. Sign in with your Azure account.
139
+
1. Sign in with your Azure account to get your Hybrid Connections available with your subscriptions. The HCM does not continue to use your Azure account beyond that.
141
140
1. Choose a subscription.
142
141
1. Select the Hybrid Connections that you want the HCM to relay.
143
142
![Screenshot of Hybrid Connections][9]
@@ -224,7 +223,9 @@ The status of "Connected" means that at least one HCM is configured with that Hy
224
223
225
224
The primary reason that clients cannot connect to their endpoint is because the endpoint was specified by using an IP address instead of a DNS name. If your app cannot reach the desired endpoint and you used an IP address, switch to using a DNS name that is valid on the host where the HCM is running. Also check that the DNS name resolves properly on the host where the HCM is running. Confirm that there is connectivity from the host where the HCM is running to the Hybrid Connection endpoint.
226
225
227
-
In App Service, the tcpping tool can be invoked from the Advanced Tools (Kudu) console. This tool can tell you if you have access to a TCP endpoint, but it does not tell you if you have access to a Hybrid Connection endpoint. When you use the tool in the console against a Hybrid Connection endpoint, you are only confirming that it uses a host:port combination.
226
+
In App Service, the **tcpping** command line tool can be invoked from the Advanced Tools (Kudu) console. This tool can tell you if you have access to a TCP endpoint, but it does not tell you if you have access to a Hybrid Connection endpoint. When you use the tool in the console against a Hybrid Connection endpoint, you are only confirming that it uses a host:port combination.
227
+
228
+
If you have a command line client for your endpoint, you can test connectivity from the app console. For example, you can test access to web server endpoints by using curl.
Copy file name to clipboardExpand all lines: articles/app-service/app-service-ip-restrictions.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ ms.workload: web
13
13
ms.tgt_pltfrm: na
14
14
ms.devlang: multiple
15
15
ms.topic: article
16
-
ms.date: 05/28/2019
16
+
ms.date: 06/06/2019
17
17
ms.author: ccompy
18
18
ms.custom: seodec18
19
19
@@ -44,27 +44,27 @@ From the Access Restrictions UI, you can review the list of access restriction r
44
44
45
45
The list will show all of the current restrictions that are on your app. If you have a VNet restriction on your app, the table will show if service endpoints are enabled for Microsoft.Web. When there are no defined restrictions on your app, your app will be accessible from anywhere.
46
46
47
+
## Adding IP address rules
48
+
47
49
You can click on **[+] Add** to add a new access restriction rule. Once you add a rule, it will become effective immediately. Rules are enforced in priority order starting from the lowest number and going up. There is an implicit deny all that is in effect once you add even a single rule.
48
50
49
-
### Adding IP address rules
51
+
When creating a rule, you must select allow/deny and also the type of rule. You are also required to provide the priority value and what you are restricting access to. You can optionally add a name, and description to the rule.
50
52
51
53
52
54
53
-
When creating a rule, you must select allow/deny and also the type of rule. You are also required to provide the priority value and what you are restricting access to. You can optionally add a name, and description to the rule.
54
-
55
55
To set an IP address based rule, select a type of IPv4 or IPv6. IP Address notation must be specified in CIDR notation for both IPv4 and IPv6 addresses. To specify an exact address, you can use something like 1.2.3.4/32 where the first four octets represent your IP address and /32 is the mask. The IPv4 CIDR notation for all addresses is 0.0.0.0/0. To learn more about CIDR notation, you can read [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).
56
56
57
-
###Service endpoints
57
+
## Service endpoints
58
58
59
-
59
+
Service endpoints enables you to restrict access to selected Azure virtual network subnets. To restrict access to a specific subnet, create a restriction rule with a type of Virtual Network. You can pick the subscription, VNet, and subnet you wish to allow or deny access with. If service endpoints are not already enabled with Microsoft.Web for the subnet that you selected, it will automatically be enabled for you unless you check the box asking not to do that. The situation where you would want to enable it on the app but not the subnet is largely related to if you have the permissions to enable service endpoints on the subnet or not. If you need to get somebody else to enable service endpoints on the subnet, you can check the box and have your app configured for service endpoints in anticipation of it being enabled later on the subnet.
60
60
61
-
To restrict access to selected subnets, select a type of Virtual Network. Below that you will be able to pick the subscription, VNet, and subnet you wish to allow or deny access with. If service endpoints are not already enabled with Microsoft.Web for the subnet that you selected, it will automatically be enabled for you unless you check the box asking not to do that. The situation where you would want to enable it on the app but not the subnet is largely related to if you have the permissions to enable service endpoints on the subnet or not. If you need to get somebody else to enable service endpoints on the subnet, you can check the box and have your app configured for service endpoints in anticipation of it being enabled later on the subnet.
61
+
62
62
63
63
Service endpoints cannot be used to restrict access to apps that run in an App Service Environment. When your app is in an App Service Environment, you can control access to your app with IP access rules.
64
64
65
65
With service endpoints, you can configure your app with Application Gateways or other WAF devices. You can also configure multi-tier applications with secure backends. For more details on some of the possibilities, read [Networking features and App Service](networking-features.md).
66
66
67
-
###Managing access restriction rules
67
+
## Managing access restriction rules
68
68
69
69
You can click on any row to edit an existing access restriction rule. Edits are effective immediately including changes in priority ordering.
70
70
@@ -78,15 +78,15 @@ To delete a rule, click the **...** on your rule and then click **remove**.
When adding your first IP Restriction rule, the service will add an explicit **deny all** rule with a priority of 2147483647. In practice, the explicit **deny all** rule will be last rule executed and will block access to any IP address that is not explicitly allowed using an **Allow** rule.
84
84
85
85
For the scenario where users want to explicitly block a single IP address or IP address block, but allow everything else access, it is necessary to add an explicit **Allow All** rule.
86
86
87
87
88
88
89
-
###SCM site
89
+
## SCM site
90
90
91
91
In addition to being able to control access to your app, you can also restrict access to the scm site used by your app. The scm site is the web deploy endpoint and also the Kudu console. You can separately assign access restrictions to the scm site from the app or use the same set for both the app and the scm site. When you check the box to have the same restrictions as your app, everything is blanked out. If you uncheck the box, whatever settings you had earlier on the scm site are applied.
Copy file name to clipboardExpand all lines: articles/app-service/environment/firewall-integration.md
+16-3Lines changed: 16 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.workload: na
11
11
ms.tgt_pltfrm: na
12
12
ms.devlang: na
13
13
ms.topic: article
14
-
ms.date: 03/12/2019
14
+
ms.date: 06/11/2019
15
15
ms.author: ccompy
16
16
ms.custom: seodec18
17
17
@@ -27,6 +27,21 @@ The ASE outbound dependencies are almost entirely defined with FQDNs, which do n
27
27
28
28
The solution to securing outbound addresses lies in use of a firewall device that can control outbound traffic based on domain names. Azure Firewall can restrict outbound HTTP and HTTPS traffic based on the FQDN of the destination.
29
29
30
+
## System architecture
31
+
32
+
Deploying an ASE with outbound traffic going through a firewall device requires changing routes on the ASE subnet. Routes operate at an IP level. If you are not careful in defining your routes, you can force TCP reply traffic to source from another address. This is called asymmetric routing and it will break TCP.
33
+
34
+
There must be routes defined so that inbound traffic to the ASE can reply back the same way the traffic came in. This is true for inbound management requests and it is true for inbound application requests.
35
+
36
+
The traffic to and from an ASE must abide by the following conventions
37
+
38
+
* The traffic to Azure SQL, Storage and Event Hub are not supported with use of a firewall device. This traffic must be sent directly to those services. The way to make that happen is to configure service endpoints for those three services.
39
+
* Route table rules must be defined that send inbound management traffic back from where it came.
40
+
* Route table rules must be defined that send inbound application traffic back from where it came.
41
+
* All other traffic leaving the ASE can be sent to your firewall device with a route table rule.
42
+
43
+
![ASE with Azure Firewall connection flow][5]
44
+
30
45
## Configuring Azure Firewall with your ASE
31
46
32
47
The steps to lock down egress from your existing ASE with Azure Firewall are:
@@ -65,8 +80,6 @@ If your applications have dependencies, they need to be added to your Azure Fire
65
80
66
81
If you know the address range that your application request traffic will come from, you can add that to the route table that is assigned to your ASE subnet. If the address range is large or unspecified, then you can use a network appliance like the Application Gateway to give you one address to add to your route table. For details on configuring an Application Gateway with your ILB ASE, read [Integrating your ILB ASE with an Application Gateway](https://docs.microsoft.com/azure/app-service/environment/integrate-with-application-gateway)
67
82
68
-
![ASE with Azure Firewall connection flow][5]
69
-
70
83
This use of the Application Gateway is just one example of how to configure your system. If you did follow this path, then you would need to add a route to the ASE subnet route table so the reply traffic sent to the Application Gateway would go there directly.
The inbound management traffic provides command and control of the ASE in addition to system monitoring. The source addresses for this traffic are listed in the [ASE Management addresses][ASEManagement] document. The network security configuration needs to allow access from all IPs on ports 454 and 455. If you block access from those addresses, your ASE will become unhealthy and then become suspended.
64
+
There are 2 other ports that can show as open on a port scan, 7654 and 1221. They reply with an IP address and nothing more. They can be blocked if desired.
65
+
66
+
The inbound management traffic provides command and control of the ASE in addition to system monitoring. The source addresses for this traffic are listed in the [ASE Management addresses][ASEManagement] document. The network security configuration needs to allow access from the ASE management addresses on ports 454 and 455. If you block access from those addresses, your ASE will become unhealthy and then become suspended. The TCP traffic that comes in on ports 454 and 455 must go back out from the same VIP or you will have an asymmetric routing problem.
66
67
67
68
Within the ASE subnet, there are many ports used for internal component communication and they can change. This requires all of the ports in the ASE subnet to be accessible from the ASE subnet.
68
69
69
-
For the communication between the Azure load balancer and the ASE subnet the minimum ports that need to be open are 454, 455 and 16001. The 16001 port is used for keep alive traffic between the load balancer and the ASE. If you are using an ILB ASE, then you can lock traffic down to just the 454, 455, 16001 ports. If you are using an External ASE, then you need to take into account the normal app access ports. If you are using app assigned addresses, you need to open it to all ports. When an address is assigned to a specific app, then the load balancer will use ports that are not known of in advance to send HTTP and HTTPS traffic to the ASE.
70
+
For the communication between the Azure load balancer and the ASE subnet the minimum ports that need to be open are 454, 455 and 16001. The 16001 port is used for keep alive traffic between the load balancer and the ASE. If you are using an ILB ASE, then you can lock traffic down to just the 454, 455, 16001 ports. If you are using an External ASE, then you need to take into account the normal app access ports.
71
+
72
+
The other ports you need to concern yourself with are the application ports:
70
73
71
-
If you are using app assigned IP addresses, you need to allow traffic from the IPs assigned to your apps to the ASE subnet.
74
+
| Use | Ports |
75
+
|----------|-------------|
76
+
| HTTP/HTTPS | 80, 443 |
77
+
| FTP/FTPS | 21, 990, 10001-10020 |
78
+
| Visual Studio remote debugging | 4020, 4022, 4024 |
79
+
| Web Deploy service | 8172 |
72
80
73
-
The TCP traffic that comes in on ports 454 and 455 must go back out from the same VIP or you will have an asymmetric routing problem.
81
+
If you block the application ports, your ASE can still function but your app might not. If you are using app assigned IP addresses with an External ASE, you will need to allow traffic from the IPs assigned to your apps to the ASE subnet on the ports shown in the ASE portal > IP Addresses page.
74
82
75
83
### ASE outbound dependencies ###
76
84
77
85
For outbound access, an ASE depends on multiple external systems. Many of those system dependencies are defined with DNS names and don't map to a fixed set of IP addresses. Thus, the ASE requires outbound access from the ASE subnet to all external IPs across a variety of ports.
78
86
79
87
The ASE communicates out to internet accessible addresses on the following ports:
80
88
81
-
|Port|Uses|
89
+
|Uses|Ports|
82
90
|-----|------|
83
-
|53|DNS|
84
-
|123|NTP|
85
-
|80/443 | CRL, Windows updates, Linux dependencies, Azure services |
86
-
|1433 |Azure SQL |
87
-
|12000|Monitoring|
91
+
|DNS|53|
92
+
|NTP|123|
93
+
|8CRL, Windows updates, Linux dependencies, Azure services| 80/443|
94
+
| Azure SQL| 1433|
95
+
|Monitoring|12000|
88
96
89
-
The complete list of outbound dependencies are listed in the document that describes [Locking down App Service Environment outbound traffic](./firewall-integration.md). If the ASE loses access to its dependencies, it stops working. When that happens long enough, the ASE is suspended.
97
+
The outbound dependencies are listed in the document that describes [Locking down App Service Environment outbound traffic](./firewall-integration.md). If the ASE loses access to its dependencies, it stops working. When that happens long enough, the ASE is suspended.
90
98
91
99
### Customer DNS ###
92
100
@@ -160,12 +168,12 @@ The required entries in an NSG, for an ASE to function, are to allow traffic:
160
168
161
169
The DNS port does not need to be added as traffic to DNS is not affected by NSG rules. These ports do not include the ports that your apps require for successful use. The normal app access ports are:
0 commit comments