Configure Azure Service Bus Relaying: Breaking Through Network Boundaries

The Distributed Monitoring Challenge

Modern integration architectures span multiple networks—on-premise data centers, Azure cloud environments, partner systems, customer sites, and DMZ networks. How do you monitor BizTalk servers behind strict corporate firewalls, cloud-hosted applications in customer Azure subscriptions, or legacy systems at remote manufacturing sites?

Where Traditional Monitoring Hits Hard Limits

• Firewall Restrictions Everywhere - Corporate security policies block inbound connections, making centralized monitoring impossible without complex VPN configurations and firewall rule changes
• VPN Complexity and Cost - Site-to-site VPNs require network engineering expertise, expensive hardware, ongoing maintenance, and create single points of failure
• DMZ and Perimeter Networks - Systems in isolated security zones cannot be reached by central monitoring infrastructure without exposing production networks
• Customer/Partner Environments - You have no control over customer firewalls or network topology, making monitoring their hosted integrations nearly impossible
• Outbound-Only Policies - Many security-conscious environments allow only outbound HTTPS traffic, blocking traditional client-server monitoring architectures
• Multi-Tenant Isolation - Cloud deployments require per-customer network isolation, preventing shared monitoring infrastructure from reaching tenant-specific systems
• Dynamic IP Addresses - Cloud auto-scaling and dynamic infrastructure make static firewall rules impractical and brittle

The Breaking Point: You've deployed Nodinite centrally, but 40% of your integration estate is unreachable—cloud migrations stalled because monitoring won't work, customer environments invisible to your operations team, remote sites requiring expensive on-premise monitoring servers.

How Azure Service Bus Relaying Solves This

Microsoft Azure Relay (Service Bus relay service from Microsoft) provides a reverse connectivity pattern that fundamentally changes how distributed monitoring works. Instead of the Nodinite Core Services, the Monitoring Service and the Web API, reaching in to agents (requires inbound firewall rules), each Monitoring Agent connects out to an Azure Relay Hybrid Connection and waits for requests. Every Nodinite Monitoring Agent supports Service Bus Relaying:

• ✅ Outbound Connections Only - Monitoring Agents open persistent outbound connections to *.servicebus.windows.net, so no inbound rule is needed on the agent's network
• ✅ No Inbound Firewall Rules - The central Monitoring Service and Web API connect to the same Azure Relay endpoint, eliminating the need for VPNs, port forwarding, or DMZ configurations
• ✅ Cloud-Native Scalability - Azure handles connection pooling, load balancing, and geographic distribution automatically
• ✅ Multi-Tenant Ready - Each agent uses its own Hybrid Connection (or namespace), providing isolation between customers, partners, and environments
• ✅ Works Everywhere - Identical configuration for on-premise, Azure, AWS, customer data centers, partner networks—any location with outbound internet access
• ✅ Built-in Security - All traffic encrypted with TLS 1.2+, authenticated via Shared Access Signatures (SAS), with Azure-managed certificate infrastructure
• ✅ Cost-Effective - Pay only for actual relay usage (listener hours + data transfer), eliminating expensive VPN appliances and dedicated network infrastructure

Real-World Transformation: Install a Monitoring Agent in a customer's locked-down Azure subscription with zero networking changes—just give the agent a Relay Hybrid Connection and its SAS connection string. Within minutes, your central Nodinite deployment can monitor their BizTalk environment, execute Remote Actions, and trigger alerts, all through outbound-only connections.

Understanding the Hybrid Connection Architecture

Two Core Services call each agent through the Relay URL:

• The Monitoring Service polls Resources, runs auto-healing Remote Actions, and takes scheduled configuration backups, as its service account.
• The Web API makes every call a user waits for: Remote Actions, metrics and graphs, Remote Configuration, diagnostics, the agent's status, and custom Monitor View columns.

The relay forwards each request to the listener inside the agent, which passes it to the agent's local HTTP endpoint. HTTP methods, headers, and request bodies are preserved. The agents can run in Azure datacenters, your on-premises enterprise, or remote customer and partner sites.

Hybrid Connection architecture: the Monitoring Service and the Web API (blue) and the Monitoring Agent host (teal) all connect outbound to the Azure Relay (purple); neither side needs an inbound firewall rule. Ports for every hop are on the Monitoring Service firewall page.

Request flow: the Monitoring Service and the Web API call the agent through the relay exactly as they would over the local network. The Web Client never calls an agent itself; it goes through the Web API.

Key Components

Costs and pricing information

Running Nodinite Monitoring Agents with Service Bus Relaying incurs costs based on:

• Number of installed agents using Service Bus Relaying
• Synchronization interval set in Monitoring Agent Configuration
• State changes in exposed Resources—error-prone environments may cost more
  • For custom-coded Monitoring Agents, ensure LogText only changes when necessary
• Caching—All Nodinite Monitoring Agents support ETAG caching to reduce costs and boost performance
• Number of Remote Actions executed
• The time each agent's listener is connected: Azure Relay bills Hybrid Connections per listener hour, plus the data transferred

Note

Using Service Bus Relay requires an Azure account with a valid credit card and will incur costs.

For the current pricing, see Microsoft's Azure Relay pricing.

Configure a Monitoring Agent for Service Bus Relaying

These steps apply to any installed Monitoring Agent.

Prerequisites

• The outbound firewall rules for the relay, on both the Core Services Server (for the Monitoring Service and the Web API) and the Agent Server; see Firewall
• An Azure Subscription with a valid credit card, where your account has at least the Contributor role, to create Relay resources
• An installed agent whose local endpoint answers on the agent server, for example http://localhost:8000/Nodinite/Monitor/Agent/WindowsServer/IsAlive (see Why do Nodinite use port 8000)
• The agent's runtime installed, as listed on the agent's Prerequisites page; for example the Windows Server Monitoring Agent prerequisites

Step 1: Create the Azure Relay Namespace and Hybrid Connection

1. In the Azure Portal, create a Relay namespace. The endpoint address must be unique; for multiple agents, create one Hybrid Connection per agent, or separate namespaces.
   
   Create or select the relay namespace in the Azure Portal.
2. Inside the namespace, create a Hybrid Connection. Its name is the EntityPath.
3. Create or pick a Shared Access Signature policy and copy its name (SharedAccessKeyName, for example RootManageSharedAccessKey) and its primary or secondary key (SharedAccessKey).
   
   The Shared Access Signature policy name in the Azure Portal.
   
   The primary and secondary keys of the policy.

Step 2: Update the Agent Configuration

Important

This manual step requires RDP access and local admin rights on the Agent Server.

Open the agent's local configuration file (App.config or .exe.config) and add or update these settings under <appSettings>:

• UseAzureRelay – set to true to enable relay mode
• RelayConnectionString – paste the Azure Relay Hybrid Connection string
• HybridConnectionName – the Hybrid Connection name (EntityPath)
• LocalWcfBaseUrl – the agent's local endpoint, e.g. http://localhost:8000
• Optional: tune timeouts and concurrency for performance

Step 3: Restart the Agent Service

• Restart the Windows service hosting your agent to apply configuration changes
• Confirm the agent logs show the relay listener is online and ready

Step 4: Configure the Monitoring Agent in the Web Client

In Monitoring Agent Configuration, set the Service URL on the Connection tab, and the Authentication Key on the Security tab. Field details are on the Connection Tab and Security Tab sections.

The Service URL uses the format https://<relay-namespace>.servicebus.windows.net/<hybrid-connection-name><agent-path>, for example https://dev-relay.servicebus.windows.net/relay-hybrid-connection/Nodinite/Monitor/Agent/WindowsServer. The agent path is in the agent's README.txt.

The help text under Service URL shows the Hybrid Connection URL format and an example.

On the Security tab, check Authenticate Connection, and enter the Service Bus Relay Hybrid Connection string with EntityPath in the Authentication Key field. From Nodinite 7, the format is:

Endpoint=sb://<relay-namespace>.servicebus.windows.net/;SharedAccessKeyName=<shared-access-key-name>;SharedAccessKey=<shared-access-key>;EntityPath=<relay-hybrid-connection>

The help text below the Authentication Key field shows the Hybrid Connection string format. With Authenticate Connection checked, both the Monitoring Service and the Web API use it.

1. Endpoint—the Azure Relay namespace, sb://<relay-namespace>.servicebus.windows.net/
2. SharedAccessKeyName—the name of the Shared Access Signature policy from Step 1
3. SharedAccessKey—the primary or secondary key of that policy
4. EntityPath—the name of the Hybrid Connection; required

The Endpoint host must end in .servicebus.windows.net; relays in sovereign clouds aren't supported. The Core Services build the SAS token from this string themselves, so nothing about the relay is set in the Portal or on the Core Services Server. The policy needs Send for the Core Services, and Listen for the agent.

Important

Through the relay, the Monitoring Service and the Web API send the product's default X-ApiKey, not a key of the agent's own. A relayed agent must therefore keep the default key; the Shared Access Signature policy is what protects it. Keep the SAS key secret, and give each agent its own Hybrid Connection.

Warning

The pre-v7 format with SharedAccessKeyName=…;AuthenticationKey=… and the WCF relay binding sections (behaviorExtensions, webHttpRelayBinding) in the agent configuration file are obsolete. Use the Hybrid Connection string above.

Step 5: Test Remote Connectivity

• Use a tool like curl or Postman to send requests to the Azure Relay URL
• Include the headers the Core Services send: X-ApiKey with the default key, and ServiceBusAuthorization with a SAS token for the audience https://<relay-namespace>.servicebus.windows.net/
• Verify responses are forwarded from the local agent endpoint, then check the agent in the Web Client

Firewall

Both the Core Services Server (the Monitoring Service and the Web API) and the Agent Server open outbound connections to *.servicebus.windows.net; no inbound rules are needed. On the Core Services Server, both processes need only TCP 443, connect directly, and don't use a proxy. The ports for each hop are listed in one place:

• Monitoring Service firewall: between the Monitoring Service and the Monitoring Agents
• Windows Server Monitoring Agent: Service Bus Relaying option
• AMQP Port Configuration - 5671 and 5672 for testing and troubleshooting the AMQP ports

Troubleshooting

• 404 errors – check that the Service URL path matches the local endpoint path and that the relay strips the entity path correctly
• 401/403 errors – check the SAS policy rights and the Authentication Key string (v7 format, with EntityPath)
• 500 errors – review the agent logs for method, path, target, and status
• No answer at all – confirm UseAzureRelay=true is set, the agent service was restarted, and the outbound Firewall rules are open
• Monitoring works, but Remote Actions, configuration, or diagnostics say the agent is off-line – the Web API can't reach the relay, while the Monitoring Service can; open outbound 443 for the Web API too
• Ensure TLS 1.2 is enabled, adjust connection limits for high concurrency, and use the Azure Portal to monitor relay usage and access policies

Tip

Additional troubleshooting information may be available in the Windows Event Logs and in the agent's own diagnostic logs; see Troubleshooting Overview.

WCF Tracing of the Local Agent Endpoint

When the agent's local endpoint (LocalWcfBaseUrl) is a WCF service, you can enable WCF diagnostics logging to debug it. See Microsoft docs. Add the following <system.diagnostics> section to the local config file (.config):

Important

The Windows Service Account running the Agent must have write access to the log folder (e.g., C:\Temp\WCFlog\). Ensure the folder exists!

...
<configuration>
  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true" >
        <listeners>
             <add name="xml"/>
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
            <add name="xml"/>
        </listeners>
      </source>
      <source name="myUserTraceSource"
              switchValue="Information, ActivityTracing">
        <listeners>
            <add name="xml"/>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
        <add name="xml"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData="C:\Temp\WCFlog\Error.svclog" />
    </sharedListeners>
  </system.diagnostics>
</configuration>
...

Contact our Support for additional guidance if you cannot resolve the problem.

Next Steps

• Add or manage Monitoring Agent
• How do I configure a Monitoring Agent?
• Monitoring Service Prerequisites

Related Topics

• Monitoring Agents
• Monitoring Service
• AMQP Port Configuration - 5671 and 5672
• Why do Nodinite use port 8000
• Troubleshooting Overview
• Microsoft Service Bus Relaying
• Service Bus Relaying Pricing
• Installing Monitor Agents - Install paths and connectivity options for Monitoring Agents
• Step 12: Update Agent Configurations – v6 to v7 migration
• Step 5: Agents – Install Nodinite v7