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

Kai Zhe Zheng 206 Reputation points
2022-08-30T10:23:56.877+00:00

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:

236080-image.png

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!

Azure Firewall
Azure Firewall
An Azure network security service that is used to protect Azure Virtual Network resources.
565 questions
Azure Automation
Azure Automation
An Azure service that is used to automate, configure, and install updates across hybrid environments.
1,113 questions
Azure Update Manager
Azure Update Manager
An Azure service to centrally manages updates and compliance at scale.
218 questions
0 comments No comments
{count} votes

Accepted answer
  1. Carlos Villagomez 1,031 Reputation points Microsoft Employee
    2022-08-30T17:45:43.993+00:00

    Hi @Kai Zhe Zheng ,

    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.

    1 person found this answer helpful.
    0 comments No comments

0 additional answers

Sort by: Most helpful