Updatemanagement in Automation Account doesn't work anymore when vnet is routed to an Azure Firewall

Question

Hi,

I have a strange problem and would like to ask for support. I have an updatemanagement scheduled in an Azure Automation Account for linux and windows VMs. The updatemanagement works fine.

I have recently created an Azure firewall and routed all traffic from the subnets, where the VMs are located to the IP of the Firewall by using routing tables since it was a business requirement. The updatemanagement doesn't work anymore after this. I receive the following error:

It is the same for Linux and Windows VMs. I suspect, the connection is somehow limited because of the Azure Firewall and I need to configure the Firewall but since I don't have more information, I'm unsure what to configure. Any Ideas what is going on in the background and how to solve this issue?

Best regards!

Answer 1

Hi @Z.K.Z ,

Thank you for your post! I am just following up to share a couple of tests including how to confirm you have basic network connectivity to the required endpoints shown below:

$wsid="########-####-####-####-############"   ## workspace ID  
$aaid="########-####-####-####-############"   ## Automation ID  
$location="eus2"    ##  abbreviated region name see https://learn.microsoft.com/en-us/azure/automation/how-to/automation-region-dns-records#support-for-private-link  
Test-NetConnection ("$wsid.ods.opinsights.azure.com") -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("$wsid.oms.opinsights.azure.com") -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("$wsid.agentsvc.azure-automation.net") -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("scadvisorcontent.blob.core.windows.net") -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
  
"== Automation endpoints"  
Test-NetConnection ("$aaid.jrds.$location.azure-automation.net")   -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("$aaid.agentsvc.$location.azure-automation.net")  -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("$aaid.webhook.$location.azure-automation.net")  -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  
Test-NetConnection ("$location-jobruntimedata-prod-su1.azure-automation.net")  -port 443 | ft RemoteAddress, TcpTestSucceeded, ComputerName  

If this test succeeds, then we know it's either and issue with your certificate or it may be related to the Microsoft endpoint. We also don't allow "man in the middle" aka SSL inspection. The below test is used to confirm if we received a certificate and if we got the certificate who was the issuer as shown below:

## CheckSSL Summary version:  Confirm Issuer has not been changed to customer provided cert.  We required SSL certificate ByPass  
$wsid="########-####-####-####-############"   ## workspace ID  
$aaid="########-####-####-####-############"   ## Automation ID  
$location="eus2"    ##  abbreviated region name see https://learn.microsoft.com/en-us/azure/automation/how-to/automation-region-dns-records#support-for-private-link  
function CheckSSL($fqdn, $port=443)     
{  
    Try {$tcpsocket = New-Object Net.Sockets.TcpClient($fqdn, $port)} Catch {Write-Warning "$($_.Exception.Message) / $fqdn";break}  
    $tcpstream = $tcpsocket.GetStream()  
    ""; "-- Target: $fqdn / " + $tcpsocket.Client.RemoteEndPoint.Address.IPAddressToString  
    $sslStream = New-Object Net.Security.SslStream($tcpstream, $false)  
    $sslStream.AuthenticateAsClient($fqdn)  # if not valid will dispaly remote cerfiticate is invalid  
    $certinfo = New-Object security.cryptography.x509certificates.x509certificate2($sslStream.RemoteCertificate)  
    $sslStream | select-object | FT sslProtocol,CipherAlgorithm, HashAlgorithm,KeyExchangeAlgorithm,IsAuthenticated,IsEncrypted,IsSigned, CheckCertRevocationStatus  
    $certinfo | fT Issuer, Thumbprint  
    #$certinfo.Extensions | where {$_.Oid.FriendlyName -like 'subject alt*'} | foreach { $_.Oid.FriendlyName; $_.Format($true) }  
    $tcpsocket.Close()   
}  
CheckSSL "$wsid.ods.opinsights.azure.com"  
CheckSSL "$wsid.oms.opinsights.azure.com"  
CheckSSL "$wsid.agentsvc.azure-automation.net"  
CheckSSL "scadvisorcontent.blob.core.windows.net"  
CheckSSL "$aaid.jrds.$location.azure-automation.net"  
CheckSSL "$aaid.agentsvc.$location.azure-automation.net"  
CheckSSL "$location-jobruntimedata-prod-su1.azure-automation.net"  

These 2 tests are used to confirm the endpoints appear to be working, however, it is still possible for a firewall to block at the service level after the certificate exchange. In the latter case, you would then need to provide access to all of the endpoints listed.

Please let me know if this helps and let us know if you require any further assistance.

Thanks!
Carlos V.