Lesson Learned #520: Troubleshooting Azure SQL Database Redirect Connection over Private Endpoint
A few days ago, we handled an interesting support case where a customer encountered the following connection error when using sqlcmd to connect to their Azure SQL Database "Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired. Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: Error code 0x102. Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to servername.database.windows.net (Redirected: servername.database.windows.net\xxxx8165ccxxx,6188). Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online." At first glance, what immediately caught our attention was the port number mentioned in the error 6188. This is not the typical 1433 port that SQL Server usually listens on. Additionally, the message referenced a "Redirected" connection, which gave us the first strong clue. We asked the customer to run the following commands for diagnostics steps: ping servername.database.windows.net to identify the IP address resolved for the Azure SQL Database Server, returning a private IP: 10.1.0.200. nslookup servername.database.windows.net to confirm whether the resolution was happening through a custom DNS or public DNS. ifconfig -a to determine the local IP address of the client, which was 10.1.0.10 (our customer is using Linux environment - RedHat) With all this information in hand, we asked the customer to open a terminal on their Linux machine and execute sudo tcpdump -i eth0 host 10.1.0.200 meanwhile they are attempting to connect using another terminal with sqlcmd and we observed that the sqlcmd was: First making a request to the port 1433 that is expected And then immediately attempting a second connection to port 6188 on the same private IP. It was during this second connection attempt that the timeout occurred. After it, based on the port and the message we asked to our customer what type of connection has this server and they reported Redirect. We explained in Azure SQL, when Redirect mode is enabled, the client: Connects to the gateway on port 1433 Receives a redirection response with a new target IP and dynamic port (e.g., 6188) Attempts a new connection to the private endpoint using this port We reviewed the connection configuration and confirmed that Redirect mode was enabled. After speaking with the customer's networking and security team, we discovered that their firewall rules were blocking outbound connections to dynamic ports like 6188. We proposed two alternative solutions: Option 1: Adjust Firewall Rules Allow outbound traffic from the client’s IP (10.1.0.10) to the Private Endpoint IP (10.1.0.200) for the required range of ports used by Azure SQL in Redirect mode. This keeps the benefits of Redirect mode: Lower latency Direct database access via Private Link Reduced dependence on Azure Gateway Option 2: Switch to Proxy Mode Change the Azure SQL Server's connection policy to Proxy, which forces all traffic through port 1433 only. This is simpler for environments where security rules restrict dynamic port ranges, but it may introduce slightly higher latency. In this case, the customer opted to update the VNet's NSG and outbound firewall rules to allow the necessary range of ports for the Private Endpoint. This allowed them to retain the benefits of Redirect mode while maintaining secure, high-performance connectivity to their Azure SQL Database.Lesson Learned #519: Reusing Connections in Azure SQL DB: How Connection Pooling Caches Your Session
A few days ago, I was working on a case where a customer reported an unexpected behavior in their application: even after switching the connection policy from Proxy to Redirect, the connections were still using Proxy mode. After investigating, we found that the customer was using connection pooling, which caches connections for reuse. This meant that even after changing the connection policy, the existing connections continued using Proxy mode because they had already been established with that setting. The new policy would only apply to newly created connections, not the ones being reused from the pool. To confirm this, we ran a test using .NET and Microsoft.Data.SqlClient to analyze how the connection pool behaves and whether connections actually switch to Redirect mode when the policy changes. How Connection Pooling Works Connection pooling is designed to reuse existing database connections instead of creating a new one for every request. This improves performance by reducing latency and avoiding unnecessary authentication handshakes. However, once a connection is established, it is cached with the original settings, including: Connection policy (Proxy or Redirect) Authentication mode Connection encryption settings This means that if you change the connection policy but reuse a pooled connection, it will retain its original mode. The only way to apply the new policy is to create a new physical connection that does not come from the pool. Testing Connection Pooling Behavior For Testing the connection pooling behavior, I developed this small code in C# that basically, opens the connection, provides information about the port using and close the connection. Repeating this process 10000 times. The idea was to track active connections and check if the port and connection policy were changing after modifying the connection policy. Initially, I attemped to use netstat -ano to track active connections and monitor the local port used by each session. Unfortunately, in Azure SQL Database, local port information is not reported, making it difficult to confirm whether a connection was truly being reused at the OS level. Despite this limitation, by analyzing the session behavior and connection reuse patterns, we were able to reach a clear conclusion. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading; using System.Threading.Tasks; using Microsoft.Data.SqlClient; namespace InfoConn { using System; using System.Data; using System.Diagnostics; using System.Text.RegularExpressions; using System.Threading; using Microsoft.Data.SqlClient; class Program { static void Main() { string connectionStringProxy = "Server=tcp:servername.database.windows.net,1433;Database=db1;User Id=user1;Password=..;Pooling=True;"; Console.WriteLine("Starting Connection Pooling Test"); for (int i = 0; i < 10000; i++) { using (SqlConnection conn = new SqlConnection(connectionStringProxy)) { conn.Open(); ShowConnectionDetails(conn, i); } Thread.Sleep(5000); } Console.WriteLine("Test complete."); } static void ShowConnectionDetails(SqlConnection conn, int attempt) { string query = "SELECT session_id, client_net_address, local_net_address, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;"; using (SqlCommand cmd = new SqlCommand(query, conn)) { using (SqlDataReader reader = cmd.ExecuteReader()) { while (reader.Read()) { Console.WriteLine($"[Attempt {attempt + 1}] Session ID: {reader["session_id"]}"); Console.WriteLine($"[Attempt {attempt + 1}] Client IP: {reader["client_net_address"]}"); Console.WriteLine($"[Attempt {attempt + 1}] Local IP: {reader["local_net_address"]}"); Console.WriteLine($"[Attempt {attempt + 1}] Auth Scheme: {reader["auth_scheme"]}"); } } } RetrievePortInformation(attempt); } static void RetrievePortInformation(int attempt) { try { int currentProcessId = Process.GetCurrentProcess().Id; Console.WriteLine($"[Attempt {attempt + 1}] PID: {currentProcessId}"); string netstatOutput = RunNetstatCommand(); var match = Regex.Match(netstatOutput, $@"\s*TCP\s*(\S+):(\d+)\s*(\S+):(\d+)\s*ESTABLISHED\s*{currentProcessId}"); if (match.Success) { string localAddress = match.Groups[1].Value; string localPort = match.Groups[2].Value; string remoteAddress = match.Groups[3].Value; string remotePort = match.Groups[4].Value; Console.WriteLine($"[Attempt {attempt + 1}] Local IP: {localAddress}"); Console.WriteLine($"[Attempt {attempt + 1}] Local Port: {localPort}"); Console.WriteLine($"[Attempt {attempt + 1}] Remote IP: {remoteAddress}"); Console.WriteLine($"[Attempt {attempt + 1}] Remote Port: {remotePort}"); } else { Console.WriteLine($"[Attempt {attempt + 1}] No active TCP connection found in netstat."); } } catch (Exception ex) { Console.WriteLine($"[Attempt {attempt + 1}] Error retrieving port info: {ex.Message}"); } } static string RunNetstatCommand() { using (Process netstatProcess = new Process()) { netstatProcess.StartInfo.FileName = "netstat"; netstatProcess.StartInfo.Arguments = "-ano"; netstatProcess.StartInfo.RedirectStandardOutput = true; netstatProcess.StartInfo.UseShellExecute = false; netstatProcess.StartInfo.CreateNoWindow = true; netstatProcess.Start(); string output = netstatProcess.StandardOutput.ReadToEnd(); netstatProcess.WaitForExit(); return output; } } } }
Major annoyance - BING converts search links to BING.COM redirect links.
I don't know if there's any way around this but BING converts every search result URL into a BING.COM redirect URL. While this may seem like a good idea to Microsoft since it records click-throughs, it falls apart on direct linked documents such as PDF, images, etc. The redirect prevents you from actually copying the real link and pasting it elsewhere. For example, something as simple as xyz.com/mydoc.pdf turns into bing.com/search=?q=blahblahblahblah and on for 50+ more random characters. And you can't simply click on the link and get it from the address bar because Edge will open the document in whatever external program handles that document type (like Acrobat Reader or MS Excel). I do a fair amount of online research and this behavior is really annoying when I want to capture and reference a link directly to a document. Note that Google does NOT do this as it preserves the actual destination link in the search results. And some of the other search engines I've tried (eg Freespoke, DuckDuckGo) don't do it either.
SharePoint Admin Center redirecting to SPFx Single Sign On Redirect Page
Hello, I've got an issue currently open with Microsoft Support however they're so far have been unable to resolve why I am being redirected to the SPFx Single Sign On Redirect Page when trying to access https://tenantname-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/home or https://admin.microsoft.com/sharepoint I am automatically taken to this page: https://mytenant-admin.sharepoint.com/_forms/spfxsinglesignon.aspx#code=0.AS8AW0bSmouaik6V_eHePuABYHaI4Qh3YX5IuLXPlQweWYwvABo.AgABAAIAAAAmoFfGtYxvRrNriQdPKIZ-AgDs_wUA9P_WluBbcSJB8cYbx71lqqyGHXDLsQVhhZcLagG1nJVuzJmvdXqmMvfZLcR57oq4kV22VhbPOWpKyp9ABUF4tm7Pxs5I5_B3BPsDOD4QiS0VqO6gwAwQYNUc9pOjEloq0Bz1B1ZHnQMm-hG4V_82qj9O8Hx6rJ8JSpA9fBzhz51tsPClPQOBVpBU1fns_9bkraWscTBJnOlDTJv5hBrN1q6Fg7wqj5B2C9xdYCFBvb-VtaDifKLGrfvMUcnQ65q4QdOUogXsMT-jRVEQiLtMlqRb577n2BH0AQNrgAAOx2O4mlaICP0zryw6Gq3gZwnn8nCieusQ_zUqDUENaF9EDovxLvq-VDkNy7FUKU3lOlXqOE-j89oez7Wxpe-811wJUKVwv4nyeymNTqs4K7e1BHR-15iECb40bI65TvjzKSS-Zz9qBLu2c8vDxq18snuqpyhO_JxUIC7ya4qysOl1kexTqBjINizSrb7s94PXXJAzVBT_XuCZDPK2YaOewowrpPPzcV5d7M_HgezHDGI6_8YPZOI4SfKDWAQ4hN02LiexG71z3OtzUt1pPMErBVjzDMC1NGdNspu4f9JPAIjdBlYRbHRB0mt1HsbmJiVmbUpSDgoqz0VIBPeh_zVfhFp8Yv8qGBut6mbOCgG9IYppfX3K5j9hsEUYhKDpdSPSxcGuW2JfoOI6kD222eZ9WRyVip9WyAndCzO0yKp48op3z_5_NnqfVEWZEW4vNOkB3TZF3n8SI2OEu6eYODGjyZBKikhnMQ6o72PpO9V8lFQKejK_3-ll-Znh4nDpjkjoix8FCzAsLRydrV0I-4Zb2U4aTRDc7Z4ZkAUKyHHFjO_cIeMrw_mYmRmzF6SOsTX5cbwLcyukQiT-a9WLBg0UVQNkuQB0gruCANYYlP4d-aElOvODltEP&client_info=eyJ1aWQiOiI0MTljN2FhNS1hMzlmLTQwZGEtODQxZi02MDQ4OTA1YzliYzYiLCJ1dGlkIjoiOWFkMjQ2NWItOWE4Yi00ZThhLTk1ZmQtZTFkZTNlZTAwMTYwIn0&state=eyJpZCI6IjhhNjM0ZGQwLWYxYTgtNGE4NC1iNGQwLTcwNzAwYWQ1ODE4YyIsIm1ldGEiOnsiaW50ZXJhY3Rpb25UeXBlIjoicmVkaXJlY3QifX0%3d%7chttps%3a%2f%2fmytenant-admin.sharepoint.com%2f_layouts%2f15%2fonline%2fAdminHome.aspx%23%2fhome&session_state=3eeb8686-6f12-44cd-8159-1bb6ccf45bdb&correlation_id=5318a330-f909-411b-b997-a203bf473edb Any clue on what could be causing this as it only appears to be happening with my admin account. All other admins who have the SharePoint Admin role are able to traverse to the SharePoint Admin Center correctly. and Yes, I've tried this on 4 different browsers and several different computers - all resulting in the same issue.
How to prevent Malicious HTTP Redirections on an Exchange server
Hello All! I am attempting to assist a customer who is trying to pass PCI scans. By default, their IP addresses redirects any HTTPS (443) requests to the Exchange server's OWA. This is fine, except the scan states that the server does not pass a couple of vulnerabilities, one of them being "Redirection via Arbitrary Host Header Manipulation". As a solution, they recommended whitelisting domains, only allow permitted domains to be included in the Host header. I (for the life of me) cannot figure out how to get this to work on a server who's default website is the Exchange OWA. Every time I try to implement a rule in IIS (see: https://techcommunity.microsoft.com/t5/iis-support-blog/host-header-vulnerability/ba-p/1031958) that would redirect any requests that don't match the supplied string to the desired domain name, the page won't load and I get "ERR_TOO_MANY_REDIRECTS" presumably because of Exchange's automatic OWA redirection. Is there a way I can prevent malicious HTTP redirections without breaking OWA? To clarify: there are two domain names on our DNS that lead to the IP address of the Exchange server: mail.domain.com and vpn.otherdomain.com, obviously one is meant for mail and the other one is meant for vpn access over port 8443. The main domain (domain.com) leads to a completely different IP address that hosts their public website. I would like to change the IIS settings on the Exchange server so that mail.domain.com is the only domain allowed to be requested through an HTTP request.
One drive does continue to sycronize a site if this one change the url?
Hi, recently we changed the main url of our sharepoint sites from xxxxxx.sharepoint.com/etc to yyyyyy.sharepoint.com/etc, at the moment there is the redirect to the new url for those who will still look for the old url so they can still reach the sites. We have seen at the moment that one drive is still working on everyone's computer, but after 90 days the redirect will be stopped from microsoft. Can this create an issue in the future? will onedrive continue to syncronize the old site on everyone's computer even after the ending of the redirect? thank you so much for the attention.Lesson Learned #431: Determining Connection Type to Azure SQL Database: Proxy or Redirect
When connecting to Azure SQL Database, it's important to understand the type of connection established. Azure offers two primary connection policies: Proxy and Redirect. Knowing which one you're using can be crucial for performance considerations and troubleshooting.
Typosquatter will not recognize valid sites
I am a frequent donor on the site tik tok. Tik tok uses a payment site and Edge has it blocked. I have been unable to pass it for 30 days. The site is https://fp.us.tiktokv.com and the typosquatter thinks it is a misspelling of tiktok, but will not allow me to dismiss. Anyone else have this problem?Redirect Teams Meeting invites to Google Calendar
Hello, we activated Teams due to the Corona situation and face a problem here. We normally use GSuite as our primary tools for Mailing, Calendar and more. Now we want to schedule meetings via Microsoft Teams, which works fine so far, but we don't want invitations to be sent to the Microsoft E-Mail Account, but rather to Gmail. We use the following pattern for both our GSuite and Microsoft: "name.surname@company.com". If we invite someone from our company to a meeting, they receive an E-mail in their Microsoft Inbox, but even if we create redirect rules, they don't get the invitation redirected to their GMail. Is there a way to solve this? Thank you! Kevin
