A business application runs on a server at your premises. Customers need to connect, and the current broadband service does not provide the required inbound path.
An internet service provider (ISP) can supply a public address through its access service. A tunnel-delivered address reaches supported infrastructure over that existing connection while keeping the public allocation separate from the access ISP’s address. Either can make the server reachable. Compare routing control, address retention, support ownership and recovery work before choosing; both still need firewall policy and a working reply path.
How an ISP-provided public address reaches the server
The ISP may assign a public address to your router, route an address to a server, or offer a block under a business service. Ask which model applies. An address on the router often needs forwarding to a private LAN host; a routed address on the server has different configuration requirements.
This can be a straightforward arrangement when the connection and service terms fit the workload. The ISP controls the access link and upstream routing. You manage the customer router, firewall and application. There may be fewer separate delivery components to diagnose.
Check whether the address is stable for the life of the service, what happens during equipment replacement, and whether inbound protocols are permitted. Ask about IPv4 and IPv6 separately. “Public” describes reachability in the addressing system; “stable” describes retention under agreed conditions.
Provider network address translation (NAT) is another question. The shared address space described in RFC 6598 does not give the subscriber a directly reachable public IPv4 address. Confirm the actual service rather than treating every router internet-facing address as a hosting address.
How a tunnel-delivered public address works
A delivered-address arrangement carries traffic for an assigned public address over another connection. In Fibmesh’s supported Public IPs deployments, that transport is WireGuard. The underlying broadband or other supported internet service remains the access connection.
For direct delivery, the supported server receives the routed public address without endpoint address translation. For a gateway deployment, the gateway can forward permitted traffic to a local area network (LAN) service through the agreed routing or NAT design. These are different choices, with different effects on source visibility and target configuration.
WireGuard carries IP packets between peers; routes determine which traffic uses that interface. Its routing discussion explains why tunnel transport and traffic selection are separate concerns. The public assignment does not require every unrelated device at the site to use a new exit.
The address reservation can remain separate from the access ISP’s address under the service terms. Changing an access connection still requires a working tunnel over the new path. Applications may need to reconnect. Address retention is useful, but it is not a promise of uninterrupted sessions.
Compare configuration, support and lifecycle costs
Include more than the monthly line item when comparing proposals. List router changes, server configuration, firewall ownership, address retention, support boundaries, planned maintenance and the effort of changing DNS or partner allowlists. Use quoted terms for the actual deployment; a generic price comparison hides too many variables.
An ISP arrangement may be easier when the provider already offers suitable routing at the site. Independent delivery may be useful when the server must stay on its existing connection or when address identity should be separated from that access service. A hosted server or reverse proxy may fit better if the workload’s real requirement is an application endpoint rather than an address on local infrastructure.
Capacity still comes from a real path. A tunnel does not improve the premises’ upload connection by definition. Assess the application’s traffic, local connection behavior and agreed delivery location. Keep application encryption in place: WireGuard protection ends at its tunnel peer.
Put the migration and failure cases in writing
Before committing, describe an ordinary restart, a lost access connection and an eventual provider change. Who notices? Which configuration must be restored? Is there a recovery route for administration? What happens to the reserved address if the service is paused or ended?
Decide inbound policy and outgoing routing independently. A server can accept public connections while ordinary new internet traffic follows its ISP route, provided the response path is designed correctly. A stable outgoing identity is an additional routing requirement, not an automatic consequence of opening inbound access.
Fibmesh Public IPs is available with assisted, deployment-specific setup. Confirm supported software, address inventory, serving location and traffic policy. Historical deployments do not establish parity across every current native client, and a generic WireGuard router is not automatically a supported gateway.
The better option is the one whose path and ownership you can explain before the first outage. Keep the application where it belongs, then choose an address arrangement the team can maintain.
Explore public address delivery on your infrastructure →
