Recently it was brought to my attention that one of our Azure SQL managed instances was not sending SMTP mail via our on prem SMTP server, with an error suggesting it could not make a network connection.
But, surely not… I had checked the outbound NSG rules and on prem firewall rules, in both cases having a rule from the managed instance DNS hostanme IP src (10.67.254.222) to the on prem SMTP server dst.
That’s when I started doing some troubleshooting and noticed I was able to send out via my personal mail server hosted on the internet. So its got to be the on prem firewalls then, right?
Well… this is when I noticed something strange… after looking through the on prem firewall log for my rule I found that absolutely NO traffic was hitting it and being allowed?! How could this be so? I know the managed instance is trying to send mail out as I have been sending test mails that have been failing…
So, I decided to try and allow the whole managed instance azure subnet in my on prem rule to the SMTP servers… and… voila! We have mail flow!
But why?! After some further digging through the on prem firewall logs of the newly adapted rule I spotted an IP in the managed instance subnet making SMTP connections – 10.67.254.205.
So what is that IP address 10.67.254.205?
Good question! Its definitely not listed under the manged instance settings nor does any DNS name map to it. Its also an odd address as the managed instance subnet it resides in is a /27 providing IPs in the range 10.67.254.193 – 10.67.254.222, meaning .205 is randomly in the middle.
I also cannot find any Microsoft documentation explaining the SQL managed instance network config and interfaces used for outbound connectivity.
For now it will remain a mystery, but whats for certain is that if you want your SQL managed instance to send out SMTP via an on prem mail server you will need to allow its whole subnet.
Should save you a few hours of troubleshooting!