App Service netwerkfuncties

U kunt toepassingen op meerdere manieren in Azure App Service implementeren. Apps die worden gehost in App Service zijn standaard rechtstreeks toegankelijk via internet en kunnen alleen via internet gehoste eindpunten bereiken. Maar voor veel toepassingen moet u het inkomende en uitgaande netwerkverkeer beheren. Er zijn verschillende functies in App Service om u te helpen aan deze behoeften te voldoen. De uitdaging is om te weten welke functie moet worden gebruikt om een bepaald probleem op te lossen. Dit artikel helpt u te bepalen welke functie u wilt gebruiken, op basis van enkele voorbeelden van use cases.

Er zijn twee belangrijke implementatietypen voor Azure App Service:

• De openbare service met meerdere tenants host App Service abonnementen in de prijs-SKU's Free, Shared, Basic, Standard, Premium, PremiumV2 en PremiumV3.
• De ASE (single-tenant App Service Environment) host Isolated SKU-App Service abonnementen rechtstreeks in uw virtuele Azure-netwerk.

Welke functies u gebruikt, is afhankelijk van of u zich in de service met meerdere tenants of in een ASE bevindt.

Notitie

Netwerkfuncties zijn niet beschikbaar voor apps die zijn geïmplementeerd in Azure Arc.

Multitenant App Service netwerkfuncties

Azure App Service is een gedistribueerd systeem. De rollen die binnenkomende HTTP- of HTTPS-aanvragen verwerken, worden front-ends genoemd. De rollen die de workload van de klant hosten, worden werkrollen genoemd. Alle rollen in een App Service-implementatie bestaan in een netwerk met meerdere tenants. Omdat er veel verschillende klanten in dezelfde App Service schaaleenheid zijn, kunt u het App Service netwerk niet rechtstreeks verbinden met uw netwerk.

In plaats van de netwerken te verbinden, hebt u functies nodig om de verschillende aspecten van toepassingscommunicatie af te handelen. De functies die aanvragen naar uw app verwerken, kunnen niet worden gebruikt om problemen op te lossen wanneer u oproepen doet vanuit uw app. Op dezelfde manier kunnen de functies waarmee problemen voor oproepen vanuit uw app worden opgelost, niet worden gebruikt om problemen met uw app op te lossen.

Binnenkomende functies	Uitgaande functies
Door de app toegewezen adres	Hybride verbindingen
Toegangsbeperkingen	Gateway-vereiste integratie van virtuele netwerken
Service-eindpunten	Integratie van virtueel netwerk
Privé-eindpunten

Met uitzondering van de vermelde uitzonderingen kunt u al deze functies samen gebruiken. U kunt de functies combineren om uw problemen op te lossen.

Use cases en functies

Voor een bepaalde use-case zijn er mogelijk een paar manieren om het probleem op te lossen. Het kiezen van de beste functie gaat soms verder dan de use-case zelf. De volgende inkomende gebruiksvoorbeelden laten zien hoe u App Service-netwerkfuncties kunt gebruiken om problemen met het beheren van verkeer naar uw app op te lossen:

Inkomende use-case	Functie
Ondersteuning voor SSL-behoeften op basis van IP voor uw app	Door de app toegewezen adres
Ondersteuning voor niet-gedeeld toegewezen inkomende adressen voor uw app	Door de app toegewezen adres
Toegang tot uw app beperken vanaf een set goed gedefinieerde adressen	Toegangsbeperkingen
Toegang tot uw app beperken vanuit resources in een virtueel netwerk	Service-eindpunten Interne Load Balancer (ILB) ASE Privé-eindpunten
Uw app beschikbaar maken op een privé-IP-adres in uw virtuele netwerk	Privé-IP-adres van ILB ASE voor inkomend verkeer op een Application Gateway-exemplaar met service-eindpunten
Uw app beveiligen met een Web Application Firewall (WAF)	Application Gateway- en ILB ASE-Application Gateway met privé-eindpunten Application Gateway met service-eindpunten Azure Front Door met toegangsbeperkingen
Verkeer verdelen naar uw apps in verschillende regio's	Azure Front Door met toegangsbeperkingen
Verkeer in dezelfde regio verdelen	Application Gateway met service-eindpunten

De volgende uitgaande gebruiksvoorbeelden laten zien hoe u App Service-netwerkfuncties kunt gebruiken om uitgaande toegangsbehoeften voor uw app op te lossen:

Uitgaande use-case	Functie
Toegang tot resources in een virtueel Azure-netwerk in dezelfde regio	ASE voor integratie van virtuele netwerken
Toegang tot resources in een virtueel Azure-netwerk in een andere regio	integratie van virtuele netwerken en peering van virtuele netwerken Gateway-vereiste as-omgeving en peering van virtuele netwerken
Toegang tot resources die zijn beveiligd met service-eindpunten	ASE voor integratie van virtuele netwerken
Toegang tot resources in een particulier netwerk dat niet is verbonden met Azure	Hybride verbindingen
Toegang tot resources in Azure ExpressRoute-circuits	ASE voor integratie van virtuele netwerken
Uitgaand verkeer van uw web-app beveiligen	integratie van virtuele netwerken en netwerkbeveiligingsgroepen ASE
Uitgaand verkeer routeren vanuit uw web-app	VIRTUELE netwerkintegratie en routetabellen ASE

Standaardnetwerkgedrag

Azure App Service-schaaleenheden ondersteunen veel klanten in elke implementatie. De gratis en gedeelde SKU-abonnementen hosten workloads van klanten op werknemers met meerdere tenants. De Basic- en hogere abonnementen hosten workloads van klanten die zijn toegewezen aan slechts één App Service plan. Als u een Standard App Service-abonnement hebt, worden alle apps in dat plan uitgevoerd op dezelfde werkrol. Als u de werkrol uitschaalt, worden alle apps in dat App Service-plan gerepliceerd op een nieuwe werkrol voor elk exemplaar in uw App Service-plan.

Uitgaande adressen

De werkrol-VM's worden voor een groot deel uitgesplitst op basis van de App Service-plannen. De abonnementen Gratis, Gedeeld, Basic, Standard en Premium gebruiken allemaal hetzelfde type werkrol-VM. Het PremiumV2-abonnement gebruikt een ander VM-type. PremiumV3 gebruikt nog een ander VM-type. Wanneer u de VM-familie wijzigt, krijgt u een andere set uitgaande adressen. Als u schaalt van Standard naar PremiumV2, veranderen uw uitgaande adressen. Als u schaalt van PremiumV2 naar PremiumV3, worden uw uitgaande adressen gewijzigd. In sommige oudere schaaleenheden worden zowel de binnenkomende als uitgaande adressen gewijzigd wanneer u schaalt van Standard naar PremiumV2.

Er zijn veel adressen die worden gebruikt voor uitgaande oproepen. De uitgaande adressen die door uw app worden gebruikt voor het plaatsen van uitgaande aanroepen, worden vermeld in de eigenschappen van uw app. Deze adressen worden gedeeld door alle apps die worden uitgevoerd op dezelfde werkrol-VM-familie in de App Service-implementatie. Als u alle adressen wilt zien die uw app in een schaaleenheid kan gebruiken, is er een eigenschap met de naam possibleOutboundAddresses waarmee ze worden weergegeven.

App Service heeft veel eindpunten die worden gebruikt om de service te beheren. Deze adressen worden gepubliceerd in een afzonderlijk document en bevinden zich ook in de AppServiceManagement IP-servicetag. De AppServiceManagement tag wordt alleen gebruikt in App Service omgevingen waar u dergelijk verkeer moet toestaan. De App Service binnenkomende adressen worden bijgehouden in de AppService IP-servicetag. Er is geen IP-servicetag die de uitgaande adressen bevat die door App Service worden gebruikt.

Door de app toegewezen adres

De door de app toegewezen adresfunctie is een uitloper van de OP IP gebaseerde SSL-mogelijkheid. U opent het door SSL in te stellen met uw app. U kunt deze functie gebruiken voor OP IP gebaseerde SSL-aanroepen. U kunt deze ook gebruiken om uw app een adres te geven dat alleen deze heeft.

Wanneer u een door de app toegewezen adres gebruikt, gaat uw verkeer nog steeds via dezelfde front-endrollen die al het binnenkomende verkeer in de App Service schaaleenheid verwerken. Maar het adres dat aan uw app is toegewezen, wordt alleen gebruikt door uw app. Gebruiksvoorbeelden voor deze functie:

• Ondersteuning voor SSL-behoeften op basis van IP voor uw app.
• Stel een toegewezen adres in voor uw app die niet wordt gedeeld.

Zie Een TLS/SSL-certificaat toevoegen in Azure App Service voor meer informatie over het instellen van een adres voor uw app.

Toegangsbeperkingen

Met toegangsbeperkingen kunt u binnenkomende aanvragen filteren. De filteractie vindt plaats op de front-endrollen die upstream zijn van de werkrollen waarin uw apps worden uitgevoerd. Omdat de front-endrollen upstream zijn van de werkrollen, kunt u toegangsbeperkingen beschouwen als beveiliging op netwerkniveau voor uw apps. Zie Overzicht van toegangsbeperkingen voor meer informatie over toegangsbeperkingen.

Met deze functie kunt u een lijst maken met regels voor toestaan en weigeren die in volgorde van prioriteit worden geëvalueerd. Het is vergelijkbaar met de functie netwerkbeveiligingsgroep (NSG) in Azure-netwerken. U kunt deze functie gebruiken in een ASE of in de service met meerdere tenants. Wanneer u deze gebruikt met een ILB ASE, kunt u de toegang vanuit privéadresblokken beperken. Zie Toegangsbeperkingen configureren voor meer informatie over het inschakelen van deze functie.

Notitie

Per app kunnen maximaal 512 regels voor toegangsbeperking worden geconfigureerd.

Privé-eindpunt

Privé-eindpunt is een netwerkinterface waarmee u privé en veilig verbinding maakt met uw web-app via Een privékoppeling van Azure. Privé-eindpunt maakt gebruik van een privé-IP-adres van uw virtuele netwerk, waardoor de web-app effectief in uw virtuele netwerk wordt gebracht. Deze functie is alleen bedoeld voor inkomende stromen naar uw web-app. Zie Privé-eindpunten gebruiken voor Azure Web App voor meer informatie.

Enkele gebruiksvoorbeelden voor deze functie:

• Beperk de toegang tot uw app vanuit resources in een virtueel netwerk.
• Stel uw app beschikbaar op een privé-IP-adres in uw virtuele netwerk.
• Beveilig uw app met een WAF.

Privé-eindpunten voorkomen gegevensexfiltratie, omdat het enige dat u kunt bereiken via het privé-eindpunt, de app is waarmee deze is geconfigureerd.

Hybride verbindingen

App Service Hybride verbindingen stelt uw apps in staat om uitgaande aanroepen te doen naar opgegeven TCP-eindpunten. Het eindpunt kan zich on-premises, in een virtueel netwerk of overal bevinden waar uitgaand verkeer naar Azure op poort 443 is toegestaan. Als u de functie wilt gebruiken, moet u een relayagent met de naam Hybrid Connection Manager installeren op een Windows Server 2012 of nieuwere host. Hybrid Connection Manager moet Azure Relay kunnen bereiken op poort 443. U kunt Hybrid Connection Manager downloaden via de gebruikersinterface van App Service hybride verbindingen in de portal.

App Service hybride verbindingen is gebaseerd op de azure Relay Hybrid Connections-mogelijkheid. App Service maakt gebruik van een speciale vorm van de functie die alleen ondersteuning biedt voor uitgaande aanroepen vanuit uw app naar een TCP-host en -poort. Deze host en poort hoeven alleen op te lossen op de host waarop Hybrid Connection Manager is geïnstalleerd.

Wanneer de app in App Service een DNS-zoekopdracht uitvoert op de host en poort die in uw hybride verbinding zijn gedefinieerd, wordt het verkeer automatisch omgeleid om via de hybride verbinding naar buiten Hybrid Connection Manager. Zie hybride verbindingen App Service voor meer informatie.

Deze functie wordt vaak gebruikt voor het volgende:

• Toegang tot resources in particuliere netwerken die niet zijn verbonden met Azure met een VPN of ExpressRoute.
• Ondersteuning voor de migratie van on-premises apps naar App Service zonder dat u ondersteunende databases hoeft te verplaatsen.
• Toegang bieden met verbeterde beveiliging voor één host en poort per hybride verbinding. De meeste netwerkfuncties hebben open toegang tot een netwerk. Met hybride verbindingen kunt u slechts één host en poort bereiken.
• Behandelt scenario's die niet worden gedekt door andere uitgaande connectiviteitsmethoden.
• Ontwikkel in App Service zodanig dat de apps eenvoudig on-premises resources kunnen gebruiken.

Omdat deze functie toegang biedt tot on-premises resources zonder een binnenkomende firewallgat, is deze functie populair bij ontwikkelaars. De andere uitgaande App Service netwerkfuncties zijn gerelateerd aan Azure Virtual Network. Hybride verbindingen zijn niet afhankelijk van het doorlopen van een virtueel netwerk. Het kan worden gebruikt voor een breder scala aan netwerkbehoeften.

App Service Hybride verbindingen is niet op de hoogte van wat u er bovenop doet. U kunt het dus gebruiken om toegang te krijgen tot een database, een webservice of een willekeurige TCP-socket op een mainframe. De functie tunnelt in wezen TCP-pakketten.

Hybride verbindingen is populair voor ontwikkeling, maar wordt ook gebruikt in productietoepassingen. Het is ideaal voor toegang tot een webservice of database, maar het is niet geschikt voor situaties waarin veel verbindingen moeten worden gemaakt.

Integratie van virtueel netwerk

App Service virtuele netwerkintegratie stelt uw app in staat om uitgaande aanvragen in een virtueel Azure-netwerk te maken.

Met de functie voor integratie van virtuele netwerken kunt u de back-end van uw app in een subnet in een Resource Manager virtueel netwerk plaatsen. Het virtuele netwerk moet zich in dezelfde regio bevinden als uw app. Deze functie is niet beschikbaar vanaf een App Service Environment, die zich al in een virtueel netwerk bevindt. Gebruiksvoorbeelden voor deze functie:

• Toegang tot resources in Resource Manager virtuele netwerken in dezelfde regio.
• Toegang tot resources in gekoppelde virtuele netwerken, inclusief regio-verbindingen.
• Toegang tot resources die zijn beveiligd met service-eindpunten.
• Toegang tot resources die toegankelijk zijn via ExpressRoute- of VPN-verbindingen.
• Toegang tot resources in particuliere netwerken zonder de noodzaak en kosten van een Virtual Network-gateway.
• Hulp bij het beveiligen van al het uitgaande verkeer.
• Al het uitgaande verkeer geforceerd tunnelen.

Zie App Service virtuele netwerkintegratie voor meer informatie.

Gateway-vereiste integratie van virtuele netwerken

Gateway-vereiste integratie van virtuele netwerken was de eerste editie van de integratie van virtuele netwerken in App Service. De functie werkt door de host waarop uw app wordt uitgevoerd, te verbinden met een Virtual Network gateway in uw virtuele netwerk met behulp van een punt-naar-site-VPN. Wanneer u de functie configureert, krijgt uw app een van de punt-naar-site-toegewezen adressen die aan elk exemplaar zijn toegewezen.

Met gatewayintegratie kunt u rechtstreeks verbinding maken met een virtueel netwerk in een andere regio zonder peering en verbinding maken met een klassiek virtueel netwerk. De functie is beperkt tot App Service Windows-abonnementen en werkt niet met virtuele netwerken die zijn verbonden met ExpressRoute. Het wordt aanbevolen om de integratie van regionale virtuele netwerken te gebruiken. Zie App Service virtuele netwerkintegratie voor meer informatie over deze functie.

App Service-omgeving

Een App Service Environment (ASE) is een implementatie met één tenant van de Azure App Service die wordt uitgevoerd in uw virtuele netwerk. Enkele gevallen, zoals voor deze functie:

• Toegang tot resources in uw virtuele netwerk.
• Toegang tot resources in ExpressRoute.
• Uw apps beschikbaar maken met een privéadres in uw virtuele netwerk.
• Toegang tot resources in service-eindpunten.
• Toegang tot resources in privé-eindpunten.

Met een ASE hoeft u geen virtuele netwerkintegratie te gebruiken, omdat de ASE zich al in uw virtuele netwerk bevindt. Als u toegang wilt krijgen tot resources zoals SQL of Azure Storage via service-eindpunten, schakelt u service-eindpunten in op het ASE-subnet. Als u toegang wilt krijgen tot resources in het virtuele netwerk of privé-eindpunten in het virtuele netwerk, hoeft u geen extra configuratie uit te voeren. Als u toegang wilt krijgen tot resources in ExpressRoute, bevindt u zich al in het virtuele netwerk en hoeft u niets in de ASE of de apps erin te configureren.

Omdat de apps in een ILB ASE kunnen worden weergegeven op een privé-IP-adres, kunt u eenvoudig WAF-apparaten toevoegen om alleen de apps die u wilt beschikbaar te maken op internet en de rest veilig te houden. Deze functie kan de ontwikkeling van toepassingen met meerdere lagen vereenvoudigen.

Sommige dingen zijn momenteel niet mogelijk vanuit de service met meerdere tenants, maar wel vanuit een ASE. Hier volgen enkele voorbeelden:

• Uw apps hosten in een service met één tenant.
• Schaal omhoog naar veel meer exemplaren dan mogelijk is in de service met meerdere tenants.
• Persoonlijke CA-clientcertificaten laden voor gebruik door uw apps met privé-CA-beveiligde eindpunten.
• TLS 1.2 forceren voor alle apps die in het systeem worden gehost, zonder dat u dit op app-niveau kunt uitschakelen.

De ASE biedt het beste verhaal over het hosten van geïsoleerde en toegewezen apps, maar brengt wel enkele beheeruitdagingen met zich mee. Enkele zaken die u moet overwegen voordat u een operationele ASE gebruikt:

• Een ASE wordt uitgevoerd binnen uw virtuele netwerk, maar heeft wel afhankelijkheden buiten het virtuele netwerk. Deze afhankelijkheden moeten worden toegestaan. Zie Netwerkoverwegingen voor een App Service Environment voor meer informatie.
• Een ASE wordt niet onmiddellijk geschaald zoals de service met meerdere tenants. U moet anticiperen op schaalbehoeften in plaats van reactief te schalen.
• Een ASE heeft wel hogere kosten vooraf. Als u optimaal gebruik wilt maken van uw ASE, moet u plannen om veel workloads in één ASE te plaatsen in plaats van deze te gebruiken voor kleine inspanningen.
• De apps in een ASE kunnen de toegang tot sommige apps in de ASE niet selectief beperken.
• Een ASE bevindt zich in een subnet en eventuele netwerkregels zijn van toepassing op al het verkeer van en naar die ASE. Als u regels voor inkomend verkeer voor slechts één app wilt toewijzen, gebruikt u toegangsbeperkingen.

Functies combineren

De functies die zijn genoteerd voor de service met meerdere tenants kunnen samen worden gebruikt om uitgebreidere gebruiksvoorbeelden op te lossen. Twee van de meest voorkomende gebruiksvoorbeelden worden hier beschreven, maar dat zijn slechts voorbeelden. Door te begrijpen wat de verschillende functies doen, kunt u aan bijna al uw systeemarchitectuurbehoeften voldoen.

Een app in een virtueel netwerk plaatsen

U vraagt zich misschien af hoe u een app in een virtueel netwerk kunt plaatsen. Als u uw app in een virtueel netwerk plaatst, bevinden de binnenkomende en uitgaande eindpunten voor de app zich binnen het virtuele netwerk. Een ASE is de beste manier om dit probleem op te lossen. Maar u kunt aan de meeste van uw behoeften binnen de multitenantservice voldoen door functies te combineren. U kunt bijvoorbeeld alleen intranettoepassingen hosten met persoonlijke binnenkomende en uitgaande adressen door:

• Een toepassingsgateway maken met privé-binnenkomende en uitgaande adressen.
• Binnenkomend verkeer naar uw app beveiligen met service-eindpunten.
• De functie voor integratie van virtuele netwerken gebruiken, zodat de back-end van uw app zich in uw virtuele netwerk bevindt.

Deze implementatiestijl geeft u geen speciaal adres voor uitgaand verkeer naar internet of de mogelijkheid om al het uitgaande verkeer van uw app te vergrendelen. Het geeft u veel van wat u anders alleen zou krijgen met een ASE.

Toepassingen met meerdere lagen maken

Een toepassing met meerdere lagen is een toepassing waarin de back-end-apps van de API alleen toegankelijk zijn vanuit de front-endlaag. Er zijn twee manieren om een toepassing met meerdere lagen te maken. Beide beginnen met het gebruik van integratie van virtuele netwerken om uw front-endweb-app te verbinden met een subnet in een virtueel netwerk. Als u dit doet, kan uw web-app aanroepen doen naar uw virtuele netwerk. Nadat uw front-end-app is verbonden met het virtuele netwerk, moet u beslissen hoe u de toegang tot uw API-toepassing vergrendelt. U kunt:

• Host zowel de front-end als de API-app in dezelfde ILB ASE en stel de front-end-app beschikbaar op internet met behulp van een toepassingsgateway.
• Host de front-end in de service met meerdere tenants en de back-end in een ILB ASE.
• Host zowel de front-end als de API-app in de multitenantservice.

Als u zowel de front-end- als api-app voor een toepassing met meerdere lagen host, kunt u het volgende doen:

• Uw API-toepassing beschikbaar maken met behulp van privé-eindpunten in uw virtuele netwerk:

  

• Gebruik service-eindpunten om ervoor te zorgen dat binnenkomend verkeer naar uw API-app alleen afkomstig is van het subnet dat wordt gebruikt door uw front-endweb-app:

  

Hier volgen enkele overwegingen om u te helpen bepalen welke methode u wilt gebruiken:

• Wanneer u service-eindpunten gebruikt, hoeft u alleen verkeer naar uw API-app naar het integratiesubnet te beveiligen. Service-eindpunten helpen bij het beveiligen van de API-app, maar u kunt nog steeds gegevensexfiltratie hebben van uw front-end-app naar andere apps in de App Service.
• Wanneer u privé-eindpunten gebruikt, hebt u twee subnetten in het spel, wat complexiteit toevoegt. Het privé-eindpunt is ook een resource op het hoogste niveau en voegt beheeroverhead toe. Het voordeel van het gebruik van privé-eindpunten is dat u geen mogelijkheid hebt van gegevensexfiltratie.

Beide methoden werken met meerdere front-ends. Op kleine schaal zijn service-eindpunten eenvoudiger te gebruiken omdat u eenvoudig service-eindpunten inschakelt voor de API-app in het subnet van de front-endintegratie. Naarmate u meer front-end-apps toevoegt, moet u elke API-app aanpassen om service-eindpunten op te nemen in het integratiesubnet. Wanneer u privé-eindpunten gebruikt, is er meer complexiteit, maar u hoeft niets te wijzigen in uw API-apps nadat u een privé-eindpunt hebt ingesteld.

Line-Of-Business-toepassingen

Lob-toepassingen (Line-Of-Business) zijn interne toepassingen die normaal gesproken niet toegankelijk zijn via internet. Deze toepassingen worden aangeroepen vanuit bedrijfsnetwerken waar de toegang strikt kan worden gecontroleerd. Als u een ILB ASE gebruikt, kunt u uw Line-Of-Business-toepassingen eenvoudig hosten. Als u de service met meerdere tenants gebruikt, kunt u privé-eindpunten gebruiken of service-eindpunten gebruiken in combinatie met een toepassingsgateway. Er zijn twee redenen om een toepassingsgateway met service-eindpunten te gebruiken in plaats van privé-eindpunten:

• U hebt WAF-beveiliging nodig voor uw LOB-apps.
• U wilt taken verdelen over meerdere exemplaren van uw LOB-apps.

Als geen van deze behoeften van toepassing is, kunt u beter privé-eindpunten gebruiken. Met privé-eindpunten die beschikbaar zijn in App Service, kunt u uw apps beschikbaar maken op privéadressen in uw virtuele netwerk. Het privé-eindpunt dat u in uw virtuele netwerk plaatst, kan worden bereikt via ExpressRoute- en VPN-verbindingen.

Als u privé-eindpunten configureert, worden uw apps weergegeven op een privéadres, maar u moet DNS configureren om dat adres on-premises te bereiken. Als u deze configuratie wilt laten werken, moet u de Azure DNS-privézone met uw privé-eindpunten doorsturen naar uw on-premises DNS-servers. Privézones van Azure DNS bieden geen ondersteuning voor het doorsturen van zones, maar u kunt het doorsturen van zones ondersteunen met behulp van azure DNS private resolver.

App Service poorten

Als u App Service scant, vindt u verschillende poorten die beschikbaar zijn voor binnenkomende verbindingen. Er is geen manier om de toegang tot deze poorten te blokkeren of te beheren in de service met meerdere tenants. Dit is de lijst met weergegeven poorten:

Gebruik	Poort of poorten
HTTP/HTTPS	80, 443
Beheer	454, 455
FTP/FTPS	21, 990, 10001-10300
Externe foutopsporing in Visual Studio	4020, 4022, 4024
Web Deploy-service	8172
Infrastructuurgebruik	7654, 1221