Transcript Hybrid Networking

Azure Networking
Secure Virtual Machine Networking
Aidan Finn, MVP
Technical Sales Lead, MicroWarehouse
www.mwh.ie
About Aidan Finn
Technical Sales Lead, MicroWarehouse
• MVP, Cloud & Datacenter
Management (Hyper-V)
• Experienced with Azure, Hyper-V,
Windows Server/Desktop, System
Center, and IT infrastructure
• http://www.aidanfinn.com
• http://www.petri.com/author/aidan-finn
• @joe_elway
• aidanfinn.com
www.mwh.ie I
About MicroWarehouse
Value Added Distribution
• Irish owned/located distributor
• Park West, Dublin 12, Ireland
• Distributors for:
•
•
•
•
•
•
Microsoft on-premises & cloud
Microsoft Surface
DataOn for Storage Spaces
Gridstore for Hyper-Convergence
SkyKick for Office 365 backup
And many more
• Value added distribution:
•
•
•
•
Much more than selling licenses
Get your licensing right
Sales education
Technical training
@MWHDistribution
www.mwh.ie I
www.mwh.ie
Agenda
Focusing on Azure Resource Manager (ARM)
The current & future of Azure
• Azure Service Management (ASM)
is the past:
•
•
•
•
Cloud services
Endpoints
Load balanced endpoints
FORGET EVERYTHING YOU KNOW ABOUT
ASM NETWORKING!
• Azure Resource Manager (ARM) is
the future:
•
•
•
•
•
•
CSP subscriptions
Azure Load Balancer
NAT & load balancing rules
Network security groups
VNet peering
High speed networking (SR-IOV [VAAI])
www.mwh.ie I
You Do Not Need To Be A Cisco Genius
Azure networking is software-defined
• I am not a network engineer
• I have never:
•
•
•
•
•
Created a VLAN
Configured a switch
Logged into a real router
Set up a h/w firewall
Understood BGP
• I am a server guy
• But I know
•
•
•
Some networking concepts
Routing & firewall theory
How to do some cool stuff in Azure
www.mwh.ie I
www.mwh.ie
Software Defined Networking
The Role of the VNet
Networking virtual machines
Gateway = 10.0.0.1
Subnet-1 – 10.0.0.0/24
VM01
VM02
www.mwh.ie I
Virtual Network (VNet)
Isolated by default, powered by NVGRE
10.1.0.0/24
10.1.1.0/24
10.1.0.0/24
10.1.2.0/24
10.1.1.0/24
Pepsi
10.1.2.0/24
Coca Cola
Azure
www.mwh.ie I
We Can Have Many VNets
But why would we deploy more than one VNet?
• Every VNet is isolated from every other
VNet
•
Natural security boundary between services
• A VNet cannot span Azure regions
•
Dispersed applications will require 1 VNet per
region
• Logistical reasons:
•
•
•
Enable split charging of IT services
Division of ownership/management
Company politics
www.mwh.ie I
IPv4 Address Basics
A quick reminder
• An IP address is made up of pieces:
•
•
For networks: Network prefix + subnet number
For devices: Network prefix + subnet number +
machine number
• Division is determined by subnet mask:
•
•
255.255.0.0 = /16
255.255.255.0 = /24
• Network examples:
•
•
Network address: 10.1.0.0/16
Subnets: 10.1.0.0/24, 10.1.1.0/24, 10.1.2.0/24
• Machine examples:
•
10.1.0.4, 10.1.0.5, 10.1.0.6, 10.1.0.7, …
www.mwh.ie I
Possible Address Spaces for VNets
What addresses can your VNets use?
• Azure VNets can only use private IP
address spaces
•
•
•
192.168.X.X
172.16.X.X
10.X.X.X
• Carve those spaces into:
•
•
Multiple VNets: each with a network address
Multiple subnets per VNet: each with a network
address
• We’ll get to Internet addresses & routing
later
www.mwh.ie I
Subnets
A VNet is divided into subnets, just like a LAN
• Simple example VNET:
Gateway = 10.0.0.1
• Network address: 10.0.0.0/16
Subnet-1 – 10.0.0.0/24
• Divide the IP space into 3
subnets:
• Each subnet routes to other
subnets in VNet via default
gateway
• 10.0.0.1, 10.0.1.1, 10.0.2.1
VNet – 10.0.0.0/16
• Subnet-1: 10.0.0.0/24
• Subnet-2: 10.0.1.0/24
• Subnet-2: 10.0.2.0/24
10.0.0.4
10.0.0.5
Gateway = 10.0.1.1
Subnet-2 – 10.0.1.0/24
10.0.1.4
10.0.1.5
Gateway = 10.0.2.1
Subnet-3 – 10.0.2.0/24
• Addresses available to VMs
• 10.0.0.4 – 10.0.0.254
• 10.1.0.4 – 10.0.1.254
• 10.2.0.4 – 10.0.2.254
10.0.2.4
10.0.2.5
www.mwh.ie I
Why Create Subnets?
Control your network traffic
Web: 10.3.0.0/24
• Old theory:
•
Manage broadcast
domains
• In Azure:
•
Create security
boundaries within a VNet
Different security policies
for each subnet
VNet: 10.3.0.0/16
•
10.3.0.4
10.3.0.5
Application: 10.3.1.0/24
10.3.1.4
10.3.1.5
Database: 10.3.2.0/24
10.3.2.4
10.3.2.5
www.mwh.ie I
VNet Addressing Best Practices
Some simple rules to live by
• Never assume that VNets won’t be connected
to another network
•
Plans change
• Treat each VNet as a branch office of the
company
•
•
•
This enables VNets to be connected to other networks
Do not use overlapping network addresses
10.1.0.0/16 cannot route to 10.1.0.0/16
• Don’t waste address spaces
•
•
•
VNet address: 10.0.0.0/8
Subnet-1 address: 10.0.0.0/8
Over 16 million IP addresses in 1 subnet!
www.mwh.ie I
www.mwh.ie
Virtual Machines
How Virtual Machines Are Connected
Some simple rules to live by
• A VM is always
connected to a subnet
• Some VMs can connect
to more than one subnet
•
Subnet
Virtual network appliances
• The VM is connected to
a virtual NIC
• The virtual NIC is
connected to a subnet
VM01
VM02
www.mwh.ie I
IP Address Assignment
How virtual machines get IP addresses
VNet DNS: 10.1.0.4; 10.1.0.5
• VNet is configured with
DNS server IP
addresses
•
IP Range: 10.2.0.4 - 10.2.0.254
Subnet
Azure’s own DNS service by
default
• When a VM starts, vNIC
is assigned:
•
•
•
•
IP address from the subnet
pool - starting with the 4th
address
Subnet mask for the subnet
Default gateway of the subnet
– 1st address in the range
DNS settings from the VNet
VM01
VM02
IP: 10.2.0.4
Subnet Mask: 255.255.255.0
Default Gateway: 10.2.0.1
DNS: 10.1.0.4; 10.1.0.5
www.mwh.ie I
It’s Actually Easy To Set Up
SDN at it’s best!
1. Create a VNet
a) Name the VNet & define location
b) Assign a network address
2. Create 1 or more subnets
a) Name each subnet
b) Assign a network address
3. Configure DNS in the VNet (optional)
4. Create VMs
a) Link to a VNet/subnet
b) Azure does the rest
www.mwh.ie I
Beware!
Leave the guest OS of the VM with DHCP configuration
www.mwh.ie I
Static or Reserved IP Addresses
How to give a VM a static IP address
• By default, VMs have dynamic private
IP addresses
•
•
VM takes the first available IP address at boot up
Not guaranteed the same IP after every reboot
• You can reserve the IP of a VM
•
•
Edit the IP settings of the vNIC
Do not change the IP config of the VM guest OS
www.mwh.ie I
www.mwh.ie
Internet Connectivity
Cloud Myth #1
I’m not putting my file server/DC up in the cloud for everyone to see!
• Azure is secure by default
• Nothing is allowed into a VNet unless
you allow it
•
More later!
www.mwh.ie I
Access to the Internet
All VMs have NAT access to the Internet by default
www.mwh.ie I
Public Inbound Access From The Internet
Two methods available
• Option 1: Per-VM Public IP (PIP)
Address
•
•
Not recommended!
Each VM has a direct connection from the
Internet
• Option 2: Load Balancer
•
•
Recommended
The load balancer is the single entry point to the
VNet from the Internet
www.mwh.ie I
Per VM Public IP (PIP) Address
Allow connections from the Internet
• You can have 1 public
IP address per VM
•
Subnet
Private IP
Address
Assigned to the vNIC
Private IP
Address
• Address assigned by
Azure
• Not advisable!
•
•
•
•
Too much management
Adds cost (even if it’s
small)
Impossible to do load
balancing, etc
Only option for Basic ASeries VMs
VM01
Public IP
Address
VM02
Public IP
Address
www.mwh.ie I
Azure Load Balancer – Public Access
The recommended way to make VMs accessible from the Internet
Load Balancer
Internet
Public IP Address
Forward TCP 80 to VM1 and VM2
Forward TCP 50004 to TCP 3389 on 10.0.0.4
Probe
Availability Set
Load Balancer
Backend Pool
VM1
Private IP Address
VM2
Private IP Address
www.mwh.ie I
We’re Still Secure By Default!
Nothing is accessible yet, even with a configured Load Balancer/PIP Address
• The following only direct traffic to a
destination:
•
•
NAT rule
Load balancing rule
• The inbound traffic is still blocked!
• We’ll look at allowing the traffic later
www.mwh.ie I
Azure Load Balancer – Private Access
Load balancing for internal usage
Load Balancer
Forward TCP 5051 to VM1 and VM2
Probe
Availability Set
Load Balancer
Backend Pool
VM1
Private IP Address
VM2
Private IP Address
Load Balancer
Private IP Address
www.mwh.ie I
www.mwh.ie
Hybrid Networking
Private Network Connections to a VNet
Hybrid networking is only the start of the hybrid cloud
• It is possible to create connections into
a VNet from an external network
• Three options:
•
•
•
Point-to-site VPN
Site-to-site VPN
ExpressRoute (WAN connection)
• A common requirement:
•
You must deploy a gateway on the VNet for the
connection
www.mwh.ie I
Azure Gateway
Highly available virtual appliance
• A virtual appliance
•
•
Actually a special hidden 2-VM cluster
Managed as one virtual device
• Used to allow private connections
•
•
From an outside source
To an Azure VNet
• Max of 1 gateway per VNet
•
Deployed into small (/29) dedicated subnet
www.mwh.ie I
Point-to-Site VPN
Connections by individual “users”
•
•
•
•
•
A user creates a VPN
connection to a VNet from
their device
Private & secure tunnel
over the Internet
Managed on a per-user
basis
Management/access is
not scalable
Intended for
“administrators” as a back
door
10.1.0.0/24
10.1.1.0/24
10.1.254.0/29
Gateway
Public IP
Address
www.mwh.ie I
Site-to-Site (S2S) VPN
Connections from an external network
•
•
•
VPN connection to a VNet
from an external network
Private & secure tunnel
over the Internet
Pros:
•
•
•
•
•
Low cost
Fast deployment
Central management
Perfect for small/medium
enterprise (SME)
10.1.0.0/24
10.1.1.0/24
10.1.254.0/29
Gateway
Public IP
Address
Cons
•
•
•
Only supports connections to
VNets
Microsoft cannot give SLA for
the Internet
Not a WAN solution
LAN
www.mwh.ie I
Resilient Site-to-Site VPN
Use multiple firewalls/ISPs for highly available connection to Azure
•
•
The gateway is a virtual
appliance with two
hidden VMs
Configure 1 connection
from on-premises to
each gateway VM
•
•
•
VNet
GW VM 1
Gateway
GW VM 2
Using different ISPs
Active-active GW S2S VPN
Extend this to an onpremises firewall cluster
•
Dual redundant S2S VPN
LAN
www.mwh.ie I
ExpressRoute
Connections from an external network
• Private WAN
Connection
• Pros:
• SLA on network
connection
• Physically private network
• All Azure services
• Complex routing
• Cons:
• Limited ISP availability
• Quite expensive
www.mwh.ie I
Azure Gateway Specifications
Choosing the right spec/price band
Basic:
Policy-Based
Basic:
Standard
Route-Based
High
Performance
Ultra
Performance
Max VPN Speed
80 Mbps*
80 Mbps*
80 Mbps*
200 Mbps
?
Max S2S
Connections
1
10
10
30
?
Max ExpressRoute
Speed
500 Mbps
(deprecated)
500 Mbps
(deprecated)
100 Mbps
2000 Mbps
10,000 Mbps
P2S VPN?
No
Yes
Yes
Yes
?
Max P2S VPN
Connections
N/A
128
128
128
?
Web-to-VNet VPN
No
Yes
Yes
Yes
?
BGP Support
No
Yes
Yes
Yes
Yes
* Sometimes listed at 100 Mbps but CPU interrupt limitations restrict it to 80 Mbps
www.mwh.ie I
www.mwh.ie
Network Security Groups
Distributed Layer-4 Firewall Rules
Firewall built into the fabric
• You don’t need to deploy a firewall
appliance for simple protocol/port
firewall rules
• Create policies
• Called Network Security Groups
(NSGs)
www.mwh.ie I
Access to the Internet
All VMs have NAT access to the Internet by default
www.mwh.ie I
What is an NSG?
Components of an NSG
• A set of prioritised stateful inbound rules
• A set of prioritised stateful outbound rules
• Each rule blocks or allows based on:
•
•
•
•
•
•
•
•
Source address/location
Destination address/location
Source protocol (TCP/UDP/*)
Destination protocol (TCP/UDP/*)
Source port (range)
Destination port (range)
Direction (in/out)
Priority (to have general/granular rules)
•
Low number = high priority
www.mwh.ie I
Default Rules in a New NSG
Every NSG contains a set of default stateful inspection rules
www.mwh.ie I
Possible Scopes of an NSG
What can we assign NSGs to?
• You have two options
• Assign NSG to each Virtual NIC
•
•
Not recommended!
Too many NSGs and too complex to troubleshoot
• Assign NSG to subnet
•
•
•
•
Recommended by Microsoft!
Create set of rules in single NSG for a subnet
Deploy 1 subnet for every security policy in a VNet
VM picks up policy when joining a subnet
• You can reuse NSGs
•
•
Might not be a good idea!
Subnet specialisations could get too complex
www.mwh.ie I
www.mwh.ie
Network Virtual Appliances
Adding More to Azure Functionality
Azure focuses a lot on Layer 4
• Azure load balancer
•
Simple layer 4 load balancing rules
• Network Security Groups
•
Simple layer 4 TCP/UDP firewall rules
• What about layer 7?
•
•
•
Application layer inspection?
Handling SSL?
Advanced session affinity?
www.mwh.ie I
Azure Marketplace
A store of third party virtual appliances
• Third-party network virtual appliances
(NVAs)
• Either:
•
•
•
Free (limited) / trial
Bring-your-own-license (BYOL)
Pay-as-you-go (PAYG – Enterprise Agreements)
• Load balancers
•
Kemp, Citrix, F5, and more
• Firewalls / Web application filters
•
Barracuda, Check Point, Brocade, and more
• Consult vendors for VNet design
www.mwh.ie I
Barracuda
Web Application Firewall Cluster
www.mwh.ie I
Check Point
Security Gateway
www.mwh.ie I
www.mwh.ie
User Defined Routing
Default Routing Table
How virtual machines route by default
• Every virtual machine
routes via the subnet’s
default gateway
• Every machine routes
directly to the Internet
• How do you force traffic from
sensitive sources to route via
VPN/ExpressRoute to Internet?
Subnet-1 – 10.0.0.0/24
VNet – 10.0.0.0/16
• How do you force traffic via a
firewall appliance for
inspection/control?
Gateway = 10.0.0.1
Gateway = 10.0.1.1
Subnet-2 – 10.0.1.0/24
Web02
Web01
Gateway = 10.0.2.1
Subnet-3 – 10.0.2.0/24
DB01
DB02
www.mwh.ie I
User-Defined Routing
Override the default subnet routes
• A table of customized routes
• Assigned to a subnet
• Create routes based on:
•
•
Network address of destination network
Next hop type
•
•
•
•
•
•
Virtual network gateway
Virtual network
Internet
Virtual appliance
None
Next hop IP address (if type = virtual appliance)
www.mwh.ie I
User-Defined Routing (UDR) for DMZ
Take complete control over VNet security
• NSGs: Basic layer 4 security
• NVA: Layer 7 inspection
• UDR: Force traffic via the NVA
www.mwh.ie I
www.mwh.ie
Connecting VNets Together
Why Connect VNets
Many reasons including …
• Isolated applications need to integrate
• You need to link VNets in different
regions
•
Data replication between VMs?
• There is a need to share infrastructure
www.mwh.ie I
Option 1: VNet Peering
The first choice when available
• Peered VNets route to each other over
the Azure fabric
•
NVGRE
• Pros:
•
•
•
Simple setup
VMs communicate at full vNIC speed
Can be done between subscriptions
•
•
You must have a single admin account for both subscriptions
Can be done between ARM and ASM
•
Only in the same subscription
• Cons:
•
•
Cannot be done between ASM and ASM
Both VNets must be in the same region
www.mwh.ie I
VNet Peering – Hub & Spoke
An interesting design scenario
• Shared infrastructure
architecture
• Hub & spoke VNet design
VNet: 10.3.0.0/16
VNet: 10.2.0.0/16
• Uses VNet Peering
• User-defined routing to
route via NVA in hub
VNet
• Single gateway required
for S2S VPN
• Peering configured to allow
use of shared gateway
• Peering at spokes set to allow
inbound “remote” data
Peering
Peering
VNet: 10.1.0.0/16
Gateway
VPN
Router NVA
Customer Network
www.mwh.ie I
Option 2: VNet-to-VNet VPN
When VNet Peering is not an option
• Uses VPN connections via VNet
gateway
• Pros:
•
•
•
VNets can be in any Azure region
Can be done between ASM and ASM
Can be done between subscriptions
•
Can be completed by 2 different administrators
• Cons:
•
•
•
VMs limited to the speed of the gateway
Requires a route-based gateway in each VNet
Limited scalability (VPNs per gateway)
www.mwh.ie I
VNet Peering – Many VNets
An interesting design scenario
• A 1:1 connection
between each VNet
• Can require a lot of setup
VNet: 10.3.0.0/16
VNet: 10.2.0.0/16
• The process has improved
• Don’t get the hub &
spoke concept
VPN 3
Gateway
Gateway
VPN 1
VPN 2
Gateway
VNet: 10.1.0.0/16
www.mwh.ie I
www.mwh.ie
Layer 7 by Microsoft
Application Gateway
Layer 7 web service enhancement
•
•
•
•
•
•
•
•
HTTP load balancing
Cookie-based session affinity
SSL offload
End-to-end SSL
URL-based content routing
Multi-site routing
Websocket support
Health monitoring of backend
resources
• And in preview …
fabrikam.com
fabrikam.com
fabricam.com
contoso.com/videos
contoso.com
Application
Gateway
contoso.com/videos
contoso.com
contoso.com
www.mwh.ie I
Web Application Firewall (Preview)
Layer 7 traffic inspection & filtering
• Preconfigured with
ModSecurity and OWASP
Core Rule Set
•
•
•
•
•
•
•
•
SQL injection
Cross site scripting
Common Web Attacks
HTTP protocol violations
HTTP protocol anomalies
HTTP DoS
Bots, crawlers, and scanners
Common application
misconfigurations
fabrikam.com
fabrikam.com
fabricam.com
Web Application
Firewall
contoso.com/videos
contoso.com
Application
Gateway
contoso.com/videos
• 2 modes
• Detection
• Prevention
contoso.com
• User-defined rules coming
contoso.com
www.mwh.ie I
www.mwh.ie
More Research
More Things For You To Read About
I bet I ran out of time before reaching here!
• Traffic Manager
•
Affordable geo-load balancing & failover of
Internet services
• High speed networking (Preview)
•
SR-IOV (aka VAAI) enabling up to 25 Gbps
• IPv6 for virtual machines
• Azure Security Center
•
AI-enhanced centralized monitoring of security
www.mwh.ie I
www.mwh.ie
On-Premises
Windows Server 2016
Most of what I covered today is also in Windows Server 2016!
• Network Controller
•
•
Fabric manager ported from Azure
Centralized control of software-defined networking
• Software-defined networking (SDN):
•
•
NVGRE: since WS2012
VXLAN: added in WS2016
• Network virtualized functions (NVFs):
•
•
•
Distributed firewall (NSGs)
Load balancer
Gateways for external network connections
•
•
L3 forwarding
BGP routing
www.mwh.ie I
Azure Stack
“Azure” you can run on-premises coming in mid-2017
• Sold in pre-packaged solutions:
•
•
•
HPE
Lenovo
Dell
• Azure consistency on WS2016:
•
•
•
•
•
•
Portal
PowerShell
ARM
Storage accounts
Virtual networks
Images syndication from Azure Marketplace
• See Damian Flynn’s session later today
www.mwh.ie I
www.mwh.ie
Wrap Up
Aidan Finn
Thanks for attending!
@joe_elway
aidanfinn.com
@MWHDistribution
www.mwh.ie I