Share via

Windows Azure SQL Database Firewall (en-US)

  • Article

To help protect your data, the Windows Azure SQL Database firewall prevents all access to your SQL Database server until you specify which computers have permission. The firewall
grants access based on the originating IP address of each request. The SQL Database
firewall can be managed via Windows Azure Platform Management Portal or directly in the master database with the provided stored procedures. Besides having access to SQL Database’s server-side firewall, you must also configure your client
side firewall to have outbound ports to access SQL Database.

Note

If you wish to contribute to this page, use the Edit tab at the top (sign-in required). If you wish to provide feedback for this documentation please either send e-mail to azuredocs@microsoft.com or use the Comment field at the bottom of this page (sign-in required).

The SQL Database Access Architecture

The following diagram illustrates the SQL Database access:

In the diagram:

  • Client applications using different APIs to connect to SQL Database Server.
  • Client applications running on Windows Azure connect to SQL Database Server.
  • The minimum requirement for Management Portal for SQL Database  to connect to SQL Database Server is
        the Microsoft Services firewall rule.

Configuring Server-side Firewall Using Management Portal

Use Windows Azure Platform Management Portal to configure the SQL Database firewall settings to allow connections from your computer(s) and
/or Windows Azure services.

To configure SQL Database firewall using Windows Azure Platform Management
Portal

  1. Open a Web browser, and browse to http://windows.azure.com/.
  2. Sign in to Windows Azure Platform Management Portal.
  3. From the left pane, click Database.
  4. From the left pane, expand your subscription, and then click the SQL Database server for
        which you want to configure firewall rules.
  5. Click Firewall Rules to list the rules.
  6. Click Add to create a new firewall rule. To allow other Windows services (Web role or Worker role) to access this SQL Database server, select Allow other Windows Azure services to access this server. It creates a rule with the IP range “0.0.0.0 – 0.0.0.0”. You can use the same interface to update and delete rules.

Note: Every firewall rule must have a unique name. The name is not case sensitive.

Note: It can take as much as five minutes before a new SQL Database firewall
configuration will take effect.

For more information on configuring SQL Database firewall, see How to Configure SQL Database Firewall at
http://msdn.microsoft.com/en-us/library/ee621783.aspx.

Changing the Firewall Rules Using the SQL Database Management API

You can create and update firewall rules using the SQL Database Management API.  For more information and samples, see Creating Firewall Rules for Servers.

Changing the Firewall Rules Using T-SQL

SQL Database allows you to change the server-side firewall rules by executing
Transact-SQL on the master database with a connection to SQL Database. Only the
server-level principal login, while connected to the master database, can
configure firewall settings for your SQL Database Server.

Here are the system extended stored procedures:

  • sp_set_firewall_rule
  • sp_delete_firewall_rule

Here are some samples:

   --create a firewall rule for a single IP address
   exec sp_set_firewall_rule N'DevComputer','206.63.251.3','206.63.251.3'

   --create a firewall rule for Microsoft services and Windows Azure services
   exec sp_set_firewall_rule N'MicrosoftServices','0.0.0.0','0.0.0.0'

   --delete a firewall rule
   exec sp_delete_firewall_rule N'DevComputer'

   --get a list of the firewall rules
   select * from sys.firewall_rules

Configuring the Client-side Firewall

Network firewall and other security devices may prevent computers on the customer networks from establishing outbound connection to SQL Azure. Customers must configure their environment to allow outbound TCP connections over port TCP/1433 to enable applications and tools to connect to SQL Database.

Some networks allow all return traffic for any connection initiated internally, but other more restrictive networks also restrict return traffic to explicit access control lists. Customers may also need to explicitly allow return traffic from SQL Database IPs back into their network, depending on
how strict their policies are.  In other words, if a customer allows
outbound TCP/1433 traffic to SQL Database IPs, they also need to allow the return
traffic coming from SQL Database IPs (source port of TCP/1433) back into their
network. 

It may be more convenient for customers to allow TCP/1433 connections to the range of Microsoft’s public network addresses instead of a specific SQL Database
location. This will allow for greater flexibility; as SQL Database adds more
locations, the need to revisit customer access control lists will be reduced.

For example, the tabular Data Stream (TDS) protocol endpoint for the SQL Database North Central
US data center is data.ch1-1.database.windows.net, with an IP address of
207.46.203.22. Performing a lookup of http://ws.arin.net/whois/?queryinput=207.46.203.22 reveals Microsoft’s entire scope for this IP is 207.46.0.0/16.

The following is an example ACL setting to allow connections to the entire range of possible IP addresses for Microsoft SQL Database Service.

   Inbound ACL (outgoing traffic): permit tcp any gt 1023 host <SQL Database IP> 1433
   Outbound ACL (return traffic): permit tcp host <SQL Database IP> 1433 any gt 1023 established

The use of the “established” tag for outbound ACLs, such as in the examples below, will return traffic for customer sites to connections established within the customer site. In other words, traffic will not be allowed unless the connections are initiated within the customer site.

Important: Inbound connections are not required or recommended.

Proxy servers may need to be adjusted to allow the outbound TDS protocol over port 1433. Client-side proxy software such as Microsoft ISA client may be needed to allow client computers to use proxy servers for outbound connections.

Optional: If you have on-premises SQL Servers that need to communicate with SQL Database for data synchronization or other reasons you must ensure that your servers have an internet routable IPs.

See Also