Azure SQL Database Access with Twingate

Azure SQL Database Access with Twingate

Azure offers a variety of managed databases — Azure SQL Database, Cosmos DB, Database for PostgreSQL/MySQL/MariaDB, and more.
Best practice is to keep these services on private networks to minimize exposure and improve performance.

Twingate routes database traffic through secure Connectors, letting you enforce firewall or Private Endpoint restrictions without exposing your database publicly.

• Azure SQL Database: Securing Databases
• Self-hosted SQL Server on Azure VMs
• Optional: Securing Azure Portal Access

Prerequisites

• Remote Network & Connector – Create a Remote Network in Twingate and deploy at least one Connector:
  • For private endpoints, place Connectors inside the same VNet as your database and use their private IP addresses in firewall rules.
  • For public endpoints (when unavoidable), capture each Connector’s public IP address for allow-listing.
• Database instance – Either an Azure-managed database (e.g. Azure SQL Database) or self-hosted SQL Server running in Azure.

Azure SQL Database: Securing Databases

Azure SQL Database enforces IP-based firewall rules. When using the public endpoint, the service sees only the Connector’s public egress IP address.

Step 1 - Configure Azure Private Connectivity

• Disable Allow Azure services unless all Azure resources should connect (this adds 0.0.0.0/0).

• If using Private Endpoint, skip public IP rules and verify DNS resolves to the private IP address.

  

  

  

Step 2 – Create a Twingate Resource

• In the Twingate Admin Console, create a Resource for your Azure SQL Database host:

  • Host: <servername>.database.windows.net (found under Database -> Overview -> Server name)
  • Port: 1433

• Assign access to the relevant user group(s).

  

Step 3 – Connect to the database

With the Twingate Client running:

sqlcmd -S myserver.database.windows.net -U <username> -P <password> -d <database>

# EXAMPLE QUERY:
1> SELECT * FROM Employees;
2> GO
EmployeeID  FirstName                                          LastName                                           JobTitle                                           HireDate
----------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ----------------
          1 Alice                                              Johnson                                            Developer                                                2021-05-10
          2 Bob                                                Smith                                              Manager                                                  2019-03-22
          3 Charlie                                            Brown                                              Analyst                                                  2022-01-15

Or use Azure Data Studio, SSMS, or any SQL client.

(Optional: If Public Access is Necessary) – Configure firewall rules in Azure

• In the Azure Portal, navigate to your SQL Server → Networking → Firewall rules.

• Add a server-level firewall rule for each Connector’s public IP address:

  • Start IP = End IP = Connector’s public IP address.
  • Server-level rules apply to all databases on the server.

• For tighter scope, create database-level firewall rules via T-SQL:

  Copy

  EXECUTE sp_set_database_firewall_rule
  @name = N'TwingateConnector',
  @start_ip_address = '1.2.3.4',
  @end_ip_address   = '1.2.3.5';

Self-hosted SQL Server on Azure VMs

For SQL Server, PostgreSQL, MySQL, MongoDB, etc. running on Azure VMs:

• Assign the VM a private IP address and deploy a Connector in the same VNet.
• In NSGs or host firewall, allow inbound traffic on the DB port from the Connector’s private IP address.
• Create a Twingate Resource for the VM’s private IP address and port.
• Connect using standard clients via Twingate — no public IP address exposure needed.

Optional: Securing Azure Portal Access

The Azure Portal (portal.azure.com) manages databases, billing, and resources. You can gate access with Twingate through SSO.

Troubleshooting Database Connections

If you’re having trouble connecting to your database via Twingate, check the following common issues:

• Firewall denies connection – Ensure that the Connector’s IP address is present in either a server‑level or database‑level firewall rule. Remember that Azure SQL checks database‑level rules first, then server‑level rules.

• Too many server rules – If you exceed the 256 server‑level rule limit, move to database‑level rules or aggregate Connector IP ranges into CIDR blocks.

• Port blocked – Verify that port 1433 is open on your local firewall and corporate proxies.

• Slow Connections: Check the health of your Connectors and make sure there are no firewall rules blocking access to the database.

• Timeouts: Verify your Connectors are online, reachable, and properly configured.

• Twingate Recent Activity: In the Admin Console, open Recent Activity for the Resource to see what’s happening:

  • DNS Failed: The Client sent traffic to the Connector, but the Connector couldn’t resolve the hostname. Ensure the DNS hosted zone is tied to the VPC, the DNS server is defined as a Twingate Resource (if self-hosting), or there’s a valid route from the Connector to the DNS server.

  • Connection Failed: The Client captured the traffic, sent it to the Connector, and the Connector tried but couldn’t reach the destination. Check that a route exists between the Connector and database, IP allow lists are correct, and firewall/security group rules allow the port on both ends.

  • No Activity: The Client didn’t send traffic to the Connector. Make sure the Client is running, you have access to the Resource, and no other VPN is hijacking the connection.

For more help, see Microsoft’s Configure a server-level IP firewall rule and our Troubleshooting guide.

Related Resources

• SaaS App Gating Guide
• Connector Best Practices
• Security Policies Guide