A microservice, an agent or a device that has to listen is one that can be attacked, and one that something has to find a way to reach. Most of the plumbing we put between them starts from that premise anyway.
The billing service waits on a port for someone to call it. The agent deployed on a customer's server waits for instructions from the cloud. The gateway box in the plant room waits for a command. Each one opens a port and waits, and whoever calls it has to know its address and get through to it. Often there is a firewall in between that was put there precisely to stop inbound connections.
This post is about the usual fixes for that, why they hurt, and how Bondy Connect removes the listening socket instead of wrapping it.
Reaching something that listens, and what it costs
The usual ways of reaching a listening process all keep the port and add layers in front of it. Inside a network you own, a load balancer or ingress controller publishes the service's port, and a service mesh adds identity and routing between services. All of it assumes you run the network the service runs on.
Across a network you don't own — a customer's data centre, a home router, a factory LAN — the standard answer is a reverse VPN. The service, agent or device dials out to a VPN concentrator, and the tunnel exposes its port to the outside world through it. Nothing listens on the public internet, and a caller elsewhere can still reach it.
The reverse VPN is where the costs are clearest. It works. It also moves the problem rather than removing it:
- It is a complicated setup. Keys, tunnel endpoints, routes, subnets and firewall rules all have to agree. Each is a place to get it wrong, and a misconfigured tunnel can expose more of the remote network than the one process you meant.
- The process still listens. The port is now reachable through the tunnel instead of directly. Anyone who gets onto the VPN reaches the same socket.
- Something must run a VPN client. On constrained hardware, locked-down firmware, a third-party appliance or a customer's server you don't administer, that is sometimes not possible.
- It routes by address, not by intent. The tunnel gives you IP connectivity. You still need something above it to decide who may call which operation on which process.
Bondy Connect: every peer dials out, none listens
Bondy Connect is an application networking platform built on WAMP, the Web Application Messaging Protocol. It has one rule that matters here: connections are always opened by clients. The router never connects to a service, agent or device. Each of them connects to the router, over an ordinary outbound WebSocket or TCP connection, with TLS.
That sounds like it would stop anyone from calling them. It doesn't, because WAMP routes remote procedure calls. Once connected, a peer registers the procedures it offers, such as com.acme.billing.refund or com.acme.thermostat.set_target. A caller anywhere else on the network calls that name. The router finds the session that registered it and delivers the invocation down the connection the peer already opened. The result travels back the same way.
So a peer can receive calls without having a single open port. The firewall that blocks inbound traffic stays as it is. There is no ingress to publish, no tunnel to configure and no VPN client to install. The peer needs a WAMP client, which is an application-level library speaking over a socket it opened itself.
Events work the same way in the other direction. A peer publishes to a topic — an order placed, a reading taken — and whoever subscribed to that topic receives it, without knowing where the publisher is or how it connected.
Peers, not clients and servers
WAMP's programming model is peer-to-peer. Every participant is a peer, and one peer can play all four roles at once: caller, callee, publisher and subscriber. The billing service that registers com.acme.billing.refund can also call a fraud-check procedure and subscribe to an order topic. Nobody is "the server".
The network model is not peer-to-peer, and that is deliberate. Peers never connect to each other. Every message passes through the router. You get symmetric roles in the code and dial-out-only connections on the wire. Peers find each other by name, a procedure or topic URI, never by address.
That is the shape of an agent communication protocol. Autonomous participants offer capabilities, ask other participants for theirs and react to events. A broker in the middle decides who may talk to whom and makes sure no one needs to know where anyone else runs. The on-premises agents in the COBOL deployment below are exactly that. They publish what they extract over the one connection they opened, and the cloud side calls the procedures they register over the same connection.
The same applies to AI agents. Bondy Connect's MCP Gateway exposes a realm's procedures as MCP tools and its topics as MCP resources. An AI agent speaking the Model Context Protocol can call a procedure that a service registered from a private subnet, or that a device registered from behind a firewall. Bondy Connect authenticates and authorises it like any other caller, and the callee never learns that MCP exists.
How a call reaches a peer behind a firewall
Here is one path end to end, with a thermostat as the peer. A microservice in a private subnet or an agent on a customer's server follows exactly the same steps.
The peer opens its connection once and keeps it. Every call after that rides on it.
Callers don't need to speak WAMP. The mobile app above sends plain HTTP. Bondy Connect's built-in API Gateway maps an HTTP route to a WAMP procedure with a wamp_call action, so POST /devices/42/target becomes a call to the procedure the thermostat registered. You keep a REST API for your apps and a no-open-ports model for everything behind it.
Security is enforced at the router, once. A peer authenticates when it opens its session. Bondy Connect supports ticket, WAMP-CRA, SCRAM and cryptosign public-key authentication, among others. Services, agents, devices and users live in realms, and role-based grants decide who may register, call, publish or subscribe to which URIs. That is the layer a reverse VPN leaves you to build: not only "can this packet reach the port" but "may this caller invoke this procedure".
Addresses stop mattering. Callers name a procedure, not a host and port. A peer can change IP, move networks or reconnect through a different node, and callers never notice.
Whole sites: Bondy Connect Edge
Sometimes the thing behind the firewall is a whole site, not one peer: a factory floor, an office, a customer's data centre running a dozen services. For that, a Bondy Connect node can run as Bondy Connect Edge. The edge node dials out to a core Bondy Connect deployment over a single bridge relay connection, again with no inbound port. Local peers connect to the edge, and the edge proxies their registrations and subscriptions to the core. So a caller in the cloud reaches a procedure that only exists at that site. The edge authenticates with cryptosign, and its signing key can stay out of its config file.
Bondy Connect Edge is early. Today every registration on a bridged realm is proxied regardless of the procedure filters you configure, and the edge receives a copy of the realm's password hashes during sync. Both are documented in the bridge relay concept guide. Weigh them before bridging a realm to a less-trusted site.
In production: COBOL on the customer's premises
A European software vendor has used this approach for years, next to COBOL legacy systems. That is a place where a VPN request would never get past the customer's security team.
The vendor deploys agents on each customer's premises, close to the COBOL system. The agents extract data from it and publish that data over WAMP to a central Bondy Connect deployment in the cloud. They also register procedures, which the cloud side calls over the same connection. Each connection is opened by the agent, outbound, so the customer never has to open a single port.
On the cloud side, the vendor collects the data from every customer and uses it to provide centralised SaaS BI. The customer's firewall stays as it was. The vendor doesn't have to ask for a tunnel, a DMZ host or a firewall exception.
Side by side
| Aspect | Reverse VPN | Bondy Connect |
|---|---|---|
| Open port on the peer | Yes, reachable through the tunnel | None; the peer only dials out |
| Software on the peer's side | A VPN client | A WAMP client library |
| What gets exposed | IP connectivity to the peer | Named procedures and topics only |
| Who may call which operation | Built separately, above the tunnel | Realm grants, per URI, at the router |
| Callers find the peer by | IP address and port | Procedure or topic name |
| Plain HTTP callers | Reach the peer's own HTTP server | API Gateway maps routes to procedures |
| Whole-site connectivity | Site-to-site tunnel | Bondy Connect Edge bridge relay (early) |
| Programming model | Client/server; the peer is the server | Peer-to-peer roles: every peer can call, serve, publish and subscribe |
Try it
The reverse VPN exists because the service, agent or device has to listen. Take that away and there is nothing to tunnel to.
Bondy Connect is open source and runs on the BEAM. Start with What is an Application Network for the model. Then pick a client library from the WAMP client libraries list. Register one procedure from a service, agent or device, and call it through the API Gateway. If you are connecting whole sites, read the Bondy Connect Edge guide first, caveats included.