Build DMZ in Azure Cloud

Azure routes traffic between Azure, on-premises, and Internet resources. Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. You can override some of Azure’s system routes with custom routes, and add additional custom routes to route tables. Azure routes outbound traffic from a subnet based on the routes in a subnet’s route table.

You can a DMZ in Azure Cloud within your subscription or tenant. The concept of a DMZ or perimeter network is not new; DMZ is a layered network security approach to minimize the attack footprint of an application.

A DMZ architecture is comprised with either two layers or three layers of security and protection concept with additional user-defined routes and firewall rules. Azure network traffic to and from resources in a virtual network using network security groups and network virtual appliances.

Workload Placement in simple DMZ:

  1. Untrusted Network (Layer 1- Frontend NSG) – WAP Server, Non-domain joined computer, Exchange Edge Server
  2. Trusted Network (Layer 2 – Backend NSG) – Domain Controller, File Server, Print Server, RDS, Database and ADFS Server.

 

Simple DMZ
Simple DMZ Example Source Microsoft

Workloads Placement in advanced DMZ:

  1. Extranet (Layer 1 – External Public Facing) A Firewall Appliance
  2. Untrusted Network (Layer 2- Frontend NSG) – WAP Server, Non-domain joined computer, Exchange Edge Server
  3. Trusted Network (Layer 3 – Backend NSG) – Domain Controller, File Server, Print Server, RDS, Database and ADFS Server.

 

Advanced dmz
Advanced DMZ Example Source Microsoft

 

 Example Address Spacing

Location vNET Address Space Connectivity  to other region
Azure Australia East vNET1 10.11.0.0/16

10.12.0.0/16

Azure Australia Southeast

ExpressRoute or S2S VPN

Australia East On-premises On-prem 10.41.0.0/16

10.41.0.0/16

S2S VPN to Azure Australia East
Azure Australia Southeast vNET2 10.51.0.0/16

10.51.0.0/16

Azure Australia East

ExpressRoute or S2S VPN

Australia Southeast On-premises On-prem 10.100.0.0/16

10.101.0.0/16

S2S VPN to Azure Australia Southeast

Hybrid Network Workloads Placement

Hybrid Network.JPG
Hybrid Network Example Source Microsoft

Best Practices

Follow Azure Networking Best Practices. Follow three basic principal of Azure Networking- Segment, Control and Enforce.

  • Segment- Multiple Azure Networks within a single vNET with large IP Address space. The private IP address spaces available are in the Class A (10.0.0.0/8), Class B (172.16.0.0/12), and Class C (192.168.0.0/16) ranges. Use Trusted IP Address range (x.x.x.x/22), Untrusted IP Address Range (x.x.x.x/22).
  • Control- Create multiple NSGs, associate FrontEnd NSG and Backend NSG with untrusted and trusted network respectively to control to and from Azure. NSGs are simple, stateful packet inspection devices that use the 5-tuple (the source IP, source port, destination IP, destination port, and layer 4 protocol) approach to create allow/deny rules for network traffic.
  • Enforce – Enforce user-defined rules to allow only desired TCP & UDP traffic to the vNET, Use Virtual Network Appliance and Perimeter Networks at all times for Enterprise Azure deployment. Disable RDP at the VM level and allow RDP at the FrontEnd NSG. Use a jump box in the DMZ to access workloads.

Centralized Mailflow: NDR Remote Server returned ‘550 5.7.1 Unable to relay’

 Environment:

  • Mailbox hosted on the Exchange Online
  • Hybrid on-prem Exchange 2010/2013 with Microsoft Exchange Online
  • Centralized Mailflow configured for Exchange 2013
  • Route all emails through on-premises configured for Exchange 2010
  • Accepted domain configured either Managed or Authoritative on the Exchange Online Side 
  • MX Record pointed to third party cloud Antispam or On-prem Antispam/Firewall

 Issue: When you send email from a mailbox hosted in Exchange Online to an internal recipient or an external recipient via on-premises server, you receive a NDR ‘550 5.7.1 Unable to relay’

Root Cause: There are customers who would like to utilize existing investment on the on-premises Antispam filter or use third part cloud based Antispam filter for compliance purpose. Hence these customers configured centralized mailflow on the hybrid configuration wizard which lead to “unable to relay” NDR when they change few configuration and introduce new domain on the Exchange Online. There are many possible reasons why you have been issued with a NDR ‘550 5.7.1 Unable to relay’.

  • You have added multiple federated domains (e..g @domain1.com, @domain2.com ) but these domains (e.g. @domain1.com, @domain2.com) are not in Hybrid Configuration
  • You have added multiple federated domains (e.g. @domain1.com, @domain2.com ) and domains (e.g. @domain1.com, @domain2.com ) have been setup as “Authoritative Domain” instead of “Internal Relay” on the Exchange Online side
  • You have added multiple federated domains (e.g. @domain1.com, @domain2.com ) but you have configured Office 365 Connectors to Send and Receive Email from only One Domain e.g. domain.com. Wild card “*” not configured within the Send Connector of Exchange Online.
  • Microsoft has changed EOP IP addresses and you did not add latest EOP IP Addresses on the Receive Connector of Edge Server
  • You configured an application to use Office 365 SMTP Relay but the Receive Connector of on-premises server has not been configured to accept email from any recipient

 To remediate the root cause, follow the steps.

  1. Copy the Message Header of Original NDR and Paste on the message analyser of https://testconnectivity.microsoft.com/ website. Analyse the message. Find out which IP address the message coming from e.g. EOP APAC IP Address is 104.47.64.0/18. Make sure these EOP IP Addresses are added on the receive connector of the on-premises server. List of EOP IP Addresses are subject to change without notice. Add all EOP IP addresses on the receive connector “Inbound from Office 365”. Refer to Microsoft KB 2750145
  2. Make sure Datacentre IP Addresses are added on the Receive Connector Properties. Refer to TechNet Blog.
  3. View Extended Rights of Receive Connectors of On-premises Server.

 Get-ReceiveConnector | Get-ADPermission | where {$_.User -like ‘*anonymous*’} | ft identity,user,extendedrights,accessrights

     4. Assign Extended Rights to accept email from any recipient.

Get-ReceiveConnector Inbound from Office 365 | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

     5. Open Office 365 Connector on the Office 365 Admin Center and make sure you have entered “*” wild card as the domain

    6. Rectify SPF Record with the following records. If you have DKIM Record and DMARC Record. Rectify those records as well. SPF Record of domain.com looks like this one

 v=spf1 ip4:<Public IP Address of domain.com>, ip4: :<Public IP Address of MX Record>, ip4: :<Public IP Address of Application/devices>, include:spf.protection.outlook.com ~all

   7. Download .NET Framework 4.5 and install .NET Framework. .NET is a Pre-req. Run Hybrid Configuration wizard select desired Federated Domains, Select all CAS Servers, Type the correct public IP addresses of Edge Server, select centralised mailflow, Select Correct certificate. Complete the Wizard.

 8. Open Send Connector on the On-premises Server, Remove all the Hub/CAS servers and add Edge Servers.

 Restart Transport Services from On-premises Server

 9. On a Hybrid Configuration, you must configure Accepted Domain as Authoritative Domain on the On-premises side and Office 365 side as Internal Relay. For Example, domain1.com should be configured as Authoritative Domain on the on-premises side and domain1.com should be configured as Internal Relay on the Exchange Online side.  

 10. Open On-premises Exchange Management Shell and run Start-EdgeSynchronization start syncing Edge Transport Server.

 11. Test mailflow from internal and external sender to internal recipient

 Relevant Articles

Fix email delivery issues for error code 5.7.1 in Office 365

Exchange Online Protection IP addresses

Hybrid Mailflow Best Practices

Set up connectors to route mail between Office 365 and your own email servers

Transport Options Hybrid Deployment

 Transport Routing Hybrid Deployment