# Security said no inbound ports.

> How the cloud reaches a server it is not allowed to connect to.

- **Format:** short video, 10 steps, ~32 seconds
- **Topic:** Azure Relay Hybrid Connections — reaching an on-premises service from the cloud without opening a single inbound firewall port.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azurerelay, hybridconnections, hybridcloud, networksecurity, servicebus, systemdesign, microsoftazure, azurecloud, cloudarchitecture, onpremises, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-relay-hybrid-connection/

---
## What you'll learn

- How the cloud reaches an on-prem service with no inbound port
- Why the private side dials out to a rendezvous point instead
- When Relay beats a VPN, and when a queue beats both

## Understand it one step at a time

### 1. Your ERP is behind the firewall

The cloud app needs live stock levels. The system that has them is on a private address in Chennai.

### 2. Security says no inbound port

Open 443 inbound, get a public IP, build a DMZ, buy a certificate. Every answer is a change to the network.

### 3. A VPN is a big hammer

Not wrong — just network-level. You joined two networks to let one app read one number.

### 4. Fix: Azure Relay

A public rendezvous point in Azure that both sides connect out to. Nothing dials in to anybody.

### 5. The on-prem service dials out

An outbound TLS connection on 443 to the relay, held open. That rule was already allowed.

### 6. The cloud calls the relay

The request goes to a public Azure endpoint and comes back down the socket the ERP already opened.

### 7. One service, not your network

The relay exposes a single hybrid connection. Listen and Send are separate keys, so a caller cannot register.

### 8. No listener, no call

Relay is connectivity, not messaging. It buffers nothing — if the ERP is down, the caller fails now.

### 9. Relay, VPN or queue

Join two networks, join one service, or join nothing at all and let a queue hold the request.

### 10. Dial out, don't open in

The safest inbound rule is the one you never had to write. Let the private side start the conversation.

---

## The takeaway

**The best inbound rule is the one you never wrote**

Let the private side open the connection, and the firewall never has to change.
