TRANXACT.AI Training

Network topologies

The five connectivity options, VPN and private-connection requirements, /22 address planning, hub-and-spoke peering, DNS and certificates, egress and operator access.

Architecture and network · 22 minutes · 6 questions

For: The customer’s network and cloud platform teams, and the Ledger Architect.

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.

The five ways a customer network reaches TRANXACT Customer sideTRANXACT VPC / VNetRemote & mobile usersLoad balancer + WAFPublic HTTPSDefault · TLS 1.2+ through the WAFOffices & data centresGateway subnetSite-to-site VPNTwo IPsec tunnels per region · BGP preferredCarrier edge routerGateway subnetPrivate connectionDirect Connect · ExpressRoute · Interconnect · VPN as backupLanding zone in the same cloudPeering · private endpointPeering / private linkLowest-latency private pathHub-and-spoke landing zoneSpoke attachmentTransit hubTRANXACT attaches as a spoke
The five ways a customer network reaches TRANXACT
OptionStatusChoose it when
Public HTTPSDefaultUsers are browsers and integrations are HTTPS. No network build.
Site-to-site VPNOptionalPrivate integrations (MES, legacy) or admin restrictions.
Private connectionOptionalPredictable bandwidth and latency, or the internet path is not allowed. VPN stays as the backup path.
Peering / private linkOptionalThe customer already has a landing zone in the same cloud.
Transit hubOptionalThe landing zone is hub-and-spoke; TRANXACT attaches as a spoke.

What the network team brings

Site-to-site VPNPrivate connection
DeviceIPsec-capable firewall or router with a static public IPEdge router at a cloud meet-me location
RedundancyTwo tunnels per region to separate gatewaysRedundant circuits; VPN as backup
ProtocolIKEv2, AES-256, SHA-256, DH group 14+ (proposed)BGP over a private virtual interface
RoutingBGP preferred; static acceptedBGP with agreed ASNs and route filters
Live DRA second pair of tunnels to the DR regionA circuit or VPN to the DR region
Customer ownsDevice, ISP line, on-premise firewall rulesCircuit 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.

One way to carve a /22 into the subnets of a region Primary region · 10.40.0.0/22 · 1,024 addresses — an illustration, not a TRANXACT standard10.40.0.0/24shared subnets10.40.1.0/24nodes · AZ110.40.2.0/24nodes · AZ210.40.3.0/24nodes · AZ3ingress/26gateway/27admin/27egress (NAT)/27database ·AZ1/27database ·AZ2/27spare/27Live DR region10.40.4.0/22the same layout, never overlapping the primary or any customer, partner or landing-zone network
One way to carve a /22 into the subnets of a region
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 Group — the worked example

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.

Check what you know

Next course

Progress is kept in this browser only — it is not sent anywhere and nobody else can see it.

← All deployment courses