With a large collection of traditional SQL servers, our business has started to look into the feasibility of moving our databases over to the Microsofts ‘SQL Azure’ service. The current databases are run on IaaS machines and have their own internal IP joined to our VNET’s. They have static IP’s so providing access to them from a machine protected by a NSG is as simply as adding a new rule:
Set-AzureNetworkSecurityRule -Action Allow -DestinationAddressPrefix 126.96.36.199/32 -DestinationPortRange 1433 -Name “SQL_Database” -Priority 100 -Protocol TCP -SourceAddressPrefix 10.10.10.10/32 -SourcePortRange * -Type Outbound
The PaaS SQL server is a different kettle of fish altogether. Their dynamic nature means they will not have a static IP address – If you download a list of the subnets here you will see that maintaining a list of accurate NSG’s rules would be an exercise in futility. As of writing, there are 216 subnets in the North Europe datacenter alone. These are likely to change fairly regularly as a datacenter grows in size.
I can see no other way of allowing access to these PaaS SQL instances other than adding a rule allowing access to all of the Internet.
Set-AzureNetworkSecurityRule -Action Allow -DestinationAddressPrefix INTERNET -DestinationPortRange 1433 -Name “SQL_PaaS_Database” -Priority 100 -Protocol TCP -SourceAddressPrefix 10.10.10.10/32 -SourcePortRange * -Type Outbound
With free access to any INTERNET SQL server, shouldn’t these apps now all be in a DMZ?
We have an old Meridian phone system which is about the same size as a small car. As part of our wider strategy to move most of our core infrastructure to Azure, we have begun testing Microsofts “PSTN calling” add-on to the Skype for Business client. PSTN calling requires no on-premises infrastructure (ie SIP trunks or a session border controller) and can leverage either your internet circuit or express route links. The service has been available for some time in the US, although there is now a preview available in the UK for some select customers. For more information about the service itself, have a look here.
I have touched on our use of a squid proxy previously with regards to accessing Skype for business/O365. The need for this is necessitated mostly by my reluctance to write a firewall policy allowing end clients to access the huge range of (changing) subnets located in Azure directly. While our Cisco ASA’s do support DNS names, they do not support wildcard domains (how could they? they need to perform DNS resolution to resolve a name to an IP). Although MS best practice says “dont use a proxy, make exceptions”, I really don’t see a great way to write firewall policies to make this workable. The squid proxy provides a low latency method of accessing this vast list of URL’s for these services. We don’t do anything fancy on them – no SSL decryption, virus scanning, URL categorisation. A PAC file then defines which URL should go through Squid, and which should go through our main internet path (Zscaler FYI).
Traditionally we have protected voice traffic by marking packets with DSCP values and writing a QOS policy to protect this bandwidth. QOS really needs to be setup end to end, otherwise congestion somewhere can cause voice/video degradation. A QOS GPO will usually mark the Skype packets, as they are expected to be in a certain port range. The problem with a Squid server in the chain is that Skype will be accessed on the Squid listening port (3128) by default, not the Skype port ranges (49152:57500). You could write a GPO to mark anything going to the squid server, but what happens if non voice/video traffic goes there as well? This will be marked unintentionally. Text conversations, files, videos etc will all be tunnelled over port 3128 so we don’t be able to distinguish them by GPO.
What is the solution? I’m not so sure yet!