1. Architecting Enterprise-Ready Networking Solutions in Azure
Peter De Tender |

2. Peter De Tender www.AzurePlatformExperts.com
Microsoft Azure Architect & Trainer
Microsoft Certified Trainer – MCT
Microsoft Learning Regional Lead
Microsoft Azure MVP ( )
Ex-Microsoft Azure Engineering PM
Book author for Packt Publishing & Apress
Courseware Author and Trainer
Technical Writer
Twitter Facebook : LinkedIn :

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

4. Agenda

5. 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

6. 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)

7. 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)

8. 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

9. Azure Core Networking

10. Azure Networking Components6 4 5 4 3 2 2 1

11. 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: /16
DNS: &
IIS-VM-01
IIS-VM-02
AD-VM-01
AD-VM-02
Subnet: WEB
CIDR: /24
Subnet: AD
CIDR: /24
The Virtual Network in Azure provides the basis for all Azure IaaS Services

12. 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.

13. 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: /16
DNS: &
IIS-VM-01
IIS-VM-02
AD-VM-01
AD-VM-02
Subnet: WEB
CIDR: /24
Subnet: AD
CIDR: /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.

14. 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
App-lb.westus.cloudapp.azure.com
VM1
Public IPs are used for VMs and Load Balancers.
You can configure the DNS names for each IP.
VM2
vm2.westus.cloudapp.azure.com

15. Private IP Assignment Rules
IPs are allocated based on order of provisioning of Network Interface Cards
(1st 4 IPs are reserved)
Subnet Web: /24
1. NIC-01 = Initial Provisioning
2. NIC-02 = 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

16. DEMO
Azure Core Networking

17. Azure Load Balancing

18. 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)

19. Intranet Solution using Internal Load Balancer
Address Space: /16
Subnet Web: /24
On Premises
/16
AV Set: WEB
Access intranet over hybrid connection
AD-DC-01
WEB-01
Subnet WEB
Hybrid Connection
AD-DC-02
WEB-02
Subnet WEB
Load Balanced IP:
Other
Servers
WEB-03
Subnet WEB
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.

20. N-Tier Application with Load-Balanced Middle Tier
Virtual Network Address Space: /16
AV Set: WEB
AV Set: APP
External
Load-Balanced
Endpoint
Internal
Load-Balanced
Endpoint
WEB-01
Subnet WEB
APP-01
Subnet APPS
WEB-02
Subnet WEB
APP-02
Subnet APPS
WEB-03
Subnet WEB
APP-03
Subnet APPS
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.

21. 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

22. Network Security Groups (NSG)

23. 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

24. Network Security Groups Example
Virtual Network
Address Space: /16
Allowed via WebSecurityGroup
Subnet Web: /24
WebSecurityGroup
SRC ADDRESS PREFIX: INTERNET
SRC PORT RANGE: *
DEST PORT RANGE: 80
DEST ADDRESS PREFIX: /24
IIS-VM-01
Subnet Web
IIS-VM-02
Subnet Web
Allowed via SQLSecurityGroup
Subnet SQL: /24
SQLSecurityGroup
SRC ADDRESS PREFIX: /24
SRC PORT RANGE: *
DEST PORT RANGE: 1433
DEST ADDRESS PREFIX: /24
SQL-VM-01
Subnet SQL
SQL-VM-02
Subnet SQL
SQL-VM-03
Subnet SQL
Here we see a typical web application that is deployed to a VNET with the address space of /16 giving us 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 /24 with 256 addresses and the second is the data tier with a space of /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 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 /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 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.

25. DEMO
Network Security Group

26. User Defined Routing

27. 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.

28. 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.

29. 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.

30. VNet Peering

31. 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

32. 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

33. 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

34. 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

35. DEMO
VNet Peering

36. Azure Networking Monitoring

37. 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

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

39. 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

40. DEMO
Azure Network Watcher
Azure Security Center

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