Architecting Enterprise-Ready Networking Solutions in Azure Peter De Tender | peter@pdtit.be | @pdtit www.AzurePlatformExperts.com

Peter De Tender www.AzurePlatformExperts.com Microsoft Azure Architect & Trainer Microsoft Certified Trainer – MCT Microsoft Learning Regional Lead Microsoft Azure MVP (2013-2017) Ex-Microsoft Azure Engineering PM Book author for Packt Publishing & Apress Courseware Author and Trainer Technical Writer Email : apes@azureplatformexperts.com Twitter : @AzureAPEs Facebook : www.facebook.com/AzureAPEs LinkedIn : http://www.linkedin.com/in/pdtit

AGENDA Azure Networking Resources Building a Hybrid Network Topology Advanced Azure Networking features Demos

Agenda

Azure Networking Picture Virtual Network “Bring your own network” Segment with subnets and security groups Control traffic flow with user defined routes Network Security Groups Azure Networking Picture Azure Datacenters all over the globe, running cloud workloads

Azure Networking Picture Virtual Network “Bring your own network” Segment with subnets and security groups Control traffic flow with user defined routes Network Security Groups Azure Networking Picture Azure Datacenters all over the globe, running cloud workloads Front-End Access Load Balancing Solutions Public & Private Ips Azure DNS DDoS Protection Direct VM Access (RDP/SSH)

Azure Networking Picture Virtual Network “Bring your own network” Segment with subnets and security groups Control traffic flow with user defined routes Network Security Groups Azure Networking Picture Azure Datacenters all over the globe, running cloud workloads Back-End Access VPN Gateways Point-to-Site VPN Site-to-Site VPN ExpressRoute VNet Peering Front-End Access Load Balancing Solutions Public & Private Ips Azure DNS DDoS Protection Direct VM Access (RDP/SSH)

Azure Networking Picture Virtual Network “Bring your own network” Segment with subnets and security groups Control traffic flow with user defined routes Network Security Groups Azure Networking Picture Azure Datacenters all over the globe, running cloud workloads Back-End Access VPN Gateways Point-to-Site VPN Site-to-Site VPN ExpressRoute VNet Peering Front-End Access Load Balancing Solutions Public & Private Ips Azure DNS DDoS Protection Direct VM Access (RDP/SSH) Azure Provides End-to-End Enterprise Ready Networking Solutions

Azure Core Networking

Azure Networking Components 6 4 5 4 3 2 2 1

Microsoft Azure Virtual Networks (VNETs) Logical isolation with control over the network Create subnets and isolate traffic with network security groups Support for Static IP addresses Support for Internal Load Balancing DNS support Hybrid Connectivity Support Site-to-Site Point-to-Site ExpressRoute Virtual Network Address Space: 10.0.0.0/16 DNS: 10.0.0.4 & 10.0.0.5 IIS-VM-01 10.0.1.4 IIS-VM-02 10.0.1.5 AD-VM-01 10.0.0.4 AD-VM-02 10.0.0.5 Subnet: WEB CIDR: 10.0.1.0/24 Subnet: AD CIDR: 10.0.0.0/24 The Virtual Network in Azure provides the basis for all Azure IaaS Services

Address Space and Subnets One more non-overlapping address spaces Define subnets out of the available address spaces in the virtual network using Classless Internet Domain Routing (CIDR) Address Spaces Subnets IP Address spaces can either be private or public or both. All subnets by default are routable to each other and the internet. Azure will automatically reserve 4 IP addresses from each subnet.

Bring Your Own DNS Specify DNS Servers at the Virtual Network Level Hosted in an Azure VM External On-Premises (with hybrid connection) Virtual Machines are assigned specified DNS at boot If DNS is added after a virtual machine is running a reboot is required for assignment. Virtual Network Address Space: 10.0.0.0/16 DNS: 10.0.1.100 & 10.0.1.101 IIS-VM-01 10.0.2.4 IIS-VM-02 10.0.2.5 AD-VM-01 10.0.1.100 AD-VM-02 10.0.1.101 Subnet: WEB CIDR: 10.0.2.0/24 Subnet: AD CIDR: 10.0.1.0/24 Virtual Networks provide the ability to specify your own DNS Servers, if you do not want to use the Azure-provided ones. These could point to IP addresses of on-premises servers, such as an Active Directory Domain Controller or network appliance, a DNS service running in an Azure Virtual Machine, or anywhere else on the Internet. If you make changes to the DNS pointers in a virtual network, after Virtual Machines have already been deployed into it, then the Virtual Machines must reboot before the change will be detected.

Public IP Address A public IP can be assigned directly to a network interface or a load balancer Supports static (reserved) or dynamic assignment Optionally supports specifying a DNS label Configurable idle timeout First 5 static IPs are free vm1.westus.cloudapp.azure.com 41.67.231.67 App-lb.westus.cloudapp.azure.com VM1 104.40.27.222 Public IPs are used for VMs and Load Balancers. You can configure the DNS names for each IP. https://azure.microsoft.com/en-us/pricing/details/ip-addresses/ 54.67.27.87 VM2 vm2.westus.cloudapp.azure.com

Private IP Assignment Rules IPs are allocated based on order of provisioning of Network Interface Cards (1st 4 IPs are reserved) Subnet Web: 10.0.1.0/24 1. NIC-01 = 10.0.1.4 Initial Provisioning 2. NIC-02 = 10.0.1.5 Initial Provisioning Use Static Private IP addresses to retain IP regardless of order By default Private IP addresses are dynamic on a VNET. They are pulled from the subnets available IPS. The First 4 are reserved. Addresses are provided and re-allocated in different order based on when the machine boots. Use Static Private Ips for machines that need to always retain the same address

DEMO Azure Core Networking

Azure Load Balancing

Azure Load Balancing Solutions 1) Azure Loadbalancer “Typical Load Balancing” on Layer 4 External or Internal Load Balancing Support for TCP and UDP Protocols Health Probe (http or tcp)

Intranet Solution using Internal Load Balancer Address Space: 10.0.0.0/16 Subnet Web: 10.0.1.0/24 On Premises 192.168.0.0/16 AV Set: WEB Access intranet over hybrid connection AD-DC-01 192.168.0.1 WEB-01 Subnet WEB 10.0.1.4 Hybrid Connection http://intranet AD-DC-02 192.168.0.2 WEB-02 Subnet WEB 10.0.1.5 https://intranetapp Load Balanced IP: 10.0.1.100 Other Servers WEB-03 Subnet WEB 10.0.1.6 Here we seen an example of internal app being directed across a hybrid connection to an Interal LB which is directing traffic to 3 IIS servers.

N-Tier Application with Load-Balanced Middle Tier Virtual Network Address Space: 10.0.0.0/16 AV Set: WEB AV Set: APP External Load-Balanced Endpoint 137.135.67.39 Internal Load-Balanced Endpoint 10.0.2.100 WEB-01 Subnet WEB 10.0.1.4 APP-01 Subnet APPS 10.0.2.4 http://company.com WEB-02 Subnet WEB 10.0.1.5 APP-02 Subnet APPS 10.0.2.5 WEB-03 Subnet WEB 10.0.1.6 APP-03 Subnet APPS 10.0.2.5 An Internal LB could also be used in conjunction with an External LB. In this configuration we have an External LB which is accessed from the Internet by users and the front-end servers are then directed to an Internal LB for the App tier of the application.

Azure Load Balancing Solutions Cookie Affinity Web Application Firewall (WAF) 2) Azure Application Gateway Application Load Balancing on Layer 7 HTTP/HTTPS protocols only Session cookie affinity SSL offloading URL rerouting IIS-VM-01 App Gateway HTTP & HTTPS IIS-VM-02 SSL Offload IIS-VM-03

Network Security Groups (NSG)

Network Security Groups Overview Enables network segmentation & DMZ scenarios NSG contains a list of ACL Rules that Allow/Deny Network Traffic to VMs in a Virtual Network Restrict traffic from or to external or internal sources, but only within the region where it was created Manage using Portal, Template, or Command line Property Limits Number of NSGs associated to a subnet, VM, or Network Interface 1 NSGs per region per subscription 100* NSG rules per NSG 200* Network Security Groups are essentially firewall rules that can be applied to virtual machines and Virtual Network subnets. Only one Network Security Group can be associated with a Virtual Machine or Virtual Network subnet. When you create a Network Security Group, it is created in a specific Microsoft Azure Region. Each Network Security Group can support up to 200 rules, and each rule specifies properties such as: Inbound or outbound traffic Priority (lower numbers are processed first) Source and Destination IP addresses Source and Destination Ports Protocol: TCP or UDP Allow or Deny

Network Security Groups Example Virtual Network Address Space: 10.0.0.0/16 Allowed via WebSecurityGroup Subnet Web: 10.20.1.0/24 WebSecurityGroup SRC ADDRESS PREFIX: INTERNET SRC PORT RANGE: * DEST PORT RANGE: 80 DEST ADDRESS PREFIX: 10.20.1.0/24 IIS-VM-01 Subnet Web 10.20.1.4 IIS-VM-02 Subnet Web 10.20.1.5 Allowed via SQLSecurityGroup Subnet SQL: 10.20.2.0/24 SQLSecurityGroup SRC ADDRESS PREFIX: 10.20.1.0/24 SRC PORT RANGE: * DEST PORT RANGE: 1433 DEST ADDRESS PREFIX: 10.20.2.0/24 SQL-VM-01 Subnet SQL 10.20.2.4 SQL-VM-02 Subnet SQL 10.20.2.5 SQL-VM-03 Subnet SQL 10.20.0.6 Here we see a typical web application that is deployed to a VNET with the address space of 10.0.0.0/16 giving us 65000+ IP addresses. There are two subnets that are supporting VMs from two different tiers of the application. The first is a web tier with the address space of 10.20.1.0/24 with 256 addresses and the second is the data tier with a space of 10.20.2.0/24 also with 256 addresses. <click> Now it is important to understand that we only want traffic from the outside to talk to the web server and only the web servers should be able to talk to our SQL Servers. This will keep our data secure. So we will first create a Network Security Group called WebSecurityGroup that will allow traffic from: Source Internet The Port Range is Anything The Destination Port Range is only going to be 80 And we will only allow that traffic to the address space for this subnet, so only to machines on the 10.20.1.0 network. Next we need our Web Servers to be able to talk to the SQL Servers, so we will create a Network Security Group called SQLSecurityGroup that will allow traffic from: Source 10.20.10/24 which will only allow our IIS servers to pass traffic The Destination Port Range is only going to be 1433 which means that they will only be able to connect to SQL And we will only allow that traffic to the address space for this subnet, so only to machines on the 10.20.2.0 network. Question: Could we Remote Desktop from IIS-VM-01 to SQL-VM-01? Answer: No because the Network security group only allows destination traffic to 1433 RDP talks over port 3389.

DEMO Network Security Group

User Defined Routing

Azure Default Network Routing Traffic automatically flows between virtual machines in different subnets and even address spaces Azure has built in default routes: Routing within a subnet From a subnet to another subnet in the same virtual network To the Internet Virtual Network to Virtual Network using a VPN Gateway Virtual Network to on-premises using a VPN Gateway Azure provides for default routes based on the VNET configuration.

User Defined Routes Internet Control traffic flow in your network with custom routes Attach route tables to subnets Specify next hop for any address prefix Set default route to force tunnel all traffic to on-premises or appliance Virtual Network VM with IP Forwarding System Route FrontEnd Subnet BackEnd Subnet Default Route VM/Appliance User Defined Route Here we see the stand configuration for VNETs in azure. By default have traffic flowing into the network directly to the front-end of our application then traffic from those VMs to the backend subnet for Data from perhaps a SQL Server. When using “User Defined Routes” the traffic is directed to other VMs first for processing. In this case there could be a content switching appliance that is directing traffic to the correct VMs and then in the backend we might be putting the data through a Firewall to ensure that there isn’t malicious behavior happening in the traffic to ensure our data is secure. For example we might not allow traffic from clients connecting to our data from outside of our country.

Forced Tunneling Internet On-Premise Network Internet Security Device “Force” or redirect Internet-bound traffic to an on-premises site (per subnet) Auditing & inspecting outbound traffic from Azure Needed by many scenarios for critical security and IT policy requirements Requires a Route-based Gateway INTERNET - IPSEC Virtual Network Subnet BackEnd Subnet FrontEnd Forced Tunneling is used to direct traffic that is bound for the internet back through a corporate asset. This is typically used when required by corporate security teams.

VNet Peering

VNET Peering Connect two VNETs in the same region Utilizes the Azure Backbone network Appear as one network for connectivity Managed as separate resources Virtual Machines will experience the exact same throughput for Peered VNET as they do on the same VNET Read Bullets https://azure.microsoft.com/en-us/documentation/articles/virtual-network-peering-overview/

Why Have Multiple VNets? Most common in Enterprise Agreements with multiple subscriptions Segregating Billing Segregating Admin A VNet cannot span subscriptions External LB External LB External LB FW FW FW FW FW FW ADDC ADDC ADDC Internal LB Internal LB Internal LB ADDC ADDC ADDC IIS IIS IIS IIS IIS IIS SQL SQL SQL Monitoring Monitoring Monitoring It might be best to first discuss why an organization might need or want to have multiple virtual networks. It is common for larger enterprises to manage multiple subscriptions. In some cases, thee is 1 or more subscriptions assigned to each business unit. This separation allows for easier segregation of costs and management responsibilities. However, a virtual network cannot span subscriptions. So it becomes necessary to connect multiple virtual networks together. Marketing IT HR

Benefits of VNET Peering Low-latency, high-bandwidth connection between resources in different VNETs No bandwidth restriction (besides those imposed on VM series/size) Ability to use resources as transit points in a peered VNET (between ARM VNets only) Reduced Infrastructure Connect VNETs that use ARM model to a VNET that uses Classic model and enable full connectivity between resources (same subscription only) Resource Manager PEER Some of the benefits of VNet Peering include: No Vnet gateways are required There is no bandwidth cap imposed on peered vnets. The only limits are those on the VMs based on series and size. the ability to connect classic and ARM virtual networks together reduced overhead as the traffic traversing the Azure Backbone is not encrypted The ability do share infrastructure components so that peered vnets can use them. This cuts down on resources and complexity. Classic

Caveats of VNET Peering Vnet peering is between 2 virtual networks, and there is no derived transitive relationship Vnet address spaces cannot overlap Peered Vnets can be in different subscriptions Must be linked to the same Azure AD tenant Exception – If 1 Vnet is ARM and the other is Classic Inter-Vnet traffic is not encrypted Must bring your own DNS Default limit of 10 peerings per Vnet (Max 50) A Peering (A-B) No Implied (A-C) B Peering (B-C) As with any technical solution, there are benefits and caveats. Some things to keep in mind when planning for the use of vnet peering include: There is no transitive relationship implied between Vnets that both connect to a hub Vnet. Vnets that will be peered cannot have address spaces that overlap While peered resource manager-based vnets can be in different subscriptions, each subscription must be linked with the same Azure AD tenant. When peering a vnet in classic mode with one in resource manager mode, both must reside in the same subscription There is no option to enable encryption with vnet peering. To enable encryption you must use VPN gateways to connect Vnets Azure-based name resolution only works within the vnet it is enabled for. To enable vnet to vnet name resolution you must use your own dns servers. Be aware of the limited number of peerings per vnet. The default limit is 10 but this can be increased with a support case to the max of 50. C

DEMO VNet Peering

Azure Networking Monitoring

Azure Network Watcher Recently added Networking feature, providing Topology Variable Packet Capture IP Flow Verify Next Hop Diagnostics Logging Security Group View NSG Flow Logging VPN Gateway Troubleshooting Network Subscription Limits Role Based Access Control Connectivity

Azure Network Monitor Centralized hub for different Azure Resources Monitoring aspects: Alerts Metrics Log Analytics Service Health Application Insights Network Watcher

Azure Security Center Centralized Dashboard, focusing on Security posture of Azure and hybrid systems and applications Active in 3 different areas: General Security View Prevention Detection Networking Features: Networking Recommendations Internet Facing Endpoints security view Networking Topology security view

DEMO Azure Network Watcher Azure Security Center

AGENDA Azure Networking Resources Building a Hybrid Network Topology Advanced Azure Networking features Demos