The network is where deployments lose time — not because it is hard, but because its inputs sit with teams who were not in the sales conversation. Get them in the room early.
| Option | Status | Choose it when |
|---|---|---|
| Public HTTPS | Default | Users are browsers and integrations are HTTPS. No network build. |
| Site-to-site VPN | Optional | Private integrations (MES, legacy) or admin restrictions. |
| Private connection | Optional | Predictable bandwidth and latency, or the internet path is not allowed. VPN stays as the backup path. |
| Peering / private link | Optional | The customer already has a landing zone in the same cloud. |
| Transit hub | Optional | The landing zone is hub-and-spoke; TRANXACT attaches as a spoke. |
What the network team brings
| Site-to-site VPN | Private connection | |
|---|---|---|
| Device | IPsec-capable firewall or router with a static public IP | Edge router at a cloud meet-me location |
| Redundancy | Two tunnels per region to separate gateways | Redundant circuits; VPN as backup |
| Protocol | IKEv2, AES-256, SHA-256, DH group 14+ (proposed) | BGP over a private virtual interface |
| Routing | BGP preferred; static accepted | BGP with agreed ASNs and route filters |
| Live DR | A second pair of tunnels to the DR region | A circuit or VPN to the DR region |
| Customer owns | Device, ISP line, on-premise firewall rules | Circuit and carrier contract |
Circuits often take weeks from the carrier. Order at contract signature and run on VPN until the circuit is live.
Address planning
At least a /22 of private RFC 1918 space per region — 1,024 addresses — and a second, different /22 for the Live DR region. Neither may overlap any customer, partner or landing-zone network. Pod and service ranges are planned inside or alongside, under the same rule if routed. Avoid the provider’s reserved and link-local ranges.
Primary 10.40.0.0/22 ingress /26 · gateway /27 · admin /27 · egress /27
database AZ1 /27 · database AZ2 /27
nodes AZ1 /24 · nodes AZ2 /24 · nodes AZ3 /24
Live DR 10.40.4.0/22 same layout
Changing ranges after the build means a rebuild — an Additional Service by change request (INFRA_2.2.12). One overlap blocks VPN, peering and DR routing at once, and one missing /22 can hold the whole build.
Hub and spoke
With peering or a transit hub, TRANXACT is the spoke and the customer’s landing zone the hub; the peering is the point of demarcation. The customer owns hub routing and inspection, and must explicitly allow transitive routing — otherwise the offices behind the hub cannot reach the spoke even though the peering is up.
One name, two regions
The customer provides the FQDN, a public-CA certificate for it (unless the managed certificate option is contracted), the public DNS record, and a private zone or conditional forwarding if private access is used. TRANXACT provides ingress in both live regions behind a global traffic manager, a low TTL, region-specific hostnames for monitoring and drills, and the failover runbook.
Never .local suffixes, IP addresses or region-specific names in an integration — they break at the first failover. An expired certificate or a missing DR record is the most common avoidable outage.
Egress, and how operators get in
Every outbound destination is listed by the customer and allow-listed by TRANXACT, one service request each. Operators come in through a zero-trust or bastion point in the admin subnet, with just-in-time elevation the customer approves, MFA, and every session logged.
Calderwood’s offices use 10.0.0.0/12 and its Azure landing zone uses 10.32.0.0/13 — which covers 10.32.0.0 to 10.39.255.255. So 10.40.0.0/22 for the primary and 10.40.4.0/22 for Live DR are clear of both. Its MES sits on the VPN; its bank and tax portal go through the egress allow-list.
Try it Calderwood’s network team proposes 10.36.0.0/22 for the primary region "because it is unused on our network". Is it?
No. 10.36.0.0/22 is inside the landing zone’s 10.32.0.0/13 (10.32.0.0–10.39.255.255). It may be unused today, but it is routed to the landing zone, so peering, the VPN and DR routing would all conflict. Check the whole IP plan — offices, data centres, every cloud — not only what is in use.