In this chapter
Three machines, three areas of responsibility
A useful way to understand the deployment is to follow a phone's request. In the wider production design, gateway transport protection, mobile subscription authentication and IMS telephone services have separate responsibilities. The mobile core authenticates the subscription and builds connectivity, while IMS provides telephone registration and call control. The real network separates these responsibilities across a security gateway, a core host and an IMS edge host.
This describes responsibilities rather than a complete wiring diagram. A host can run several functions, and a process can be active without carrying the currently selected user traffic. The public Lodestar story describes the wider project. Use the beginner build in this guide as a public learning path, with the production system as an example of how responsibilities can grow.
| Host role | Observed functions | Lesson for a first build |
|---|---|---|
| Security gateway | IPsec software, a WireGuard interface and separate management networking | Optional for a remote site crossing an untrusted network; a LAN build does not need this gateway |
| Mobile core | Mobile authentication, mobility and gateway services, plus DNS and monitoring | Prove attachment and data routing before adding telephone services |
| IMS edge | IMS call control, media relay, messaging and application services | Add voice and SMS as separate tested layers |
The worked beginner topology keeps the radio and core together on an isolated private Ethernet LAN. It does not require a security gateway or backhaul IPsec tunnel. Separate production hosts explain how Lodestar is organised, not a minimum shopping list for your own first network.
The security gateway
The security gateway was running Ubuntu 22.04.5 LTS. The inspection found an active Lodestar charon service, strongSwan 5.9.5 packages, swanctl tooling, a WireGuard interface and a dedicated management VLAN. Provisioning and metadata services associated with the gateway were also active.
charon is strongSwan's IKE daemon. In a design using IPsec radio backhaul, IKE negotiates the protected association between the authorised peers. WireGuard and a management VLAN can support separate administrative access. The active software and interface inventory verifies the presence of these building blocks. It does not by itself establish which tunnels carried traffic at the moment of inspection or prove every firewall rule.
For the LAN-only build, keep the radio link on the isolated private cable or controlled VLAN and do not add an IPsec gateway merely to copy the production layout. If a future radio site crosses an untrusted network, plan transport security, peer authentication and management access for that changed topology. Any future tunnel needs its own keys, certificates or other selected peer credentials. An existing operator's credentials are neither required nor suitable. For that remote design, write down what the radio may reach through its tunnel and what an administrator may reach through the management path.
The mobile core
The core host was running Ubuntu 24.04.5 LTS. Active VectorCore services included MME, HSS, SGW control and SGW user plane roles. Open5GS SMF and UPF processes were also active, alongside NRF and SCP services. Additional gateway canary services were present. Because multiple gateway implementations were running, a service list alone cannot establish the exact live user plane route.
In plain language, the MME coordinates LTE attachment and mobility, the HSS holds subscription and authentication information, and the gateway functions organise and carry subscriber packets. The published Lodestar story describes a VectorCore serving gateway combined with Open5GS packet gateway functions. That documented design is useful context; the read-only inspection was not an end-to-end verification of it.
The host also had primary and secondary DNS proxy services, MongoDB, BIRD routing software, Prometheus, Grafana and GenieACS active. These show that operating the network involves name resolution, routing, measurement and device management as well as the mobile protocols. Their presence is not a recommendation to install every one in a first lab. Add supporting services when you can explain their purpose, access rules and recovery procedure.
The IMS edge
The IMS edge was running Ubuntu 22.04.5 LTS with Kamailio 6.1.1. Separate active services provided P-CSCF, I-CSCF, S-CSCF and SMSC application roles. Configuration structure confirmed P-CSCF registrar and IMS IPsec modules, Diameter CDP components, and S-CSCF authentication, registrar and charging modules. The P-CSCF configuration contained Rx policy function calls. These are verified configuration observations, not proof that every feature was exercised by a handset.
Diameter configuration showed IMS Cx application identifiers for I-CSCF and S-CSCF and an Rx application identifier for P-CSCF. The S-CSCF configuration also contained RTPengine offer, answer and session management calls. RTPengine 12.5.1.56 was active as the media relay.
The running FreeSWITCH executable reported version 1.11.3. This version was checked against the actual service executable, since the default shell executable was a different version. The distinction matters when troubleshooting: an installed command's version does not always identify the software serving traffic.
PostgreSQL 14, dnsmasq and Caddy were active, together with monitoring and host protection services. The network interfaces included a physical Ethernet interface and a VLAN interface. No host addresses, routing details, credentials or subscriber data are needed to understand these roles.
Messaging and customer services add more moving parts
The IMS host had active services labelled for SMS over LTE NAS, an IMS and carrier SMS adapter, durable SMS transport APIs and workers, and a multipart carrier submission worker. Subscriber provisioning, voice account, rating, telemetry and telephone application services were also active. This verifies that the production host has a wider application layer than the basic IMS call control processes.
The labels and configuration inventory do not prove the final delivery route for an individual message. They also do not mean that a fresh Kamailio installation contains Lodestar's custom applications. Treat message submission, storage, retry, carrier delivery and handset receipt as distinct stages when designing your own service.
A small private lab can begin with local subscriptions and explicit test destinations. Customer registration, prepaid rating, billing, external carrier access and account recovery should each have their own design and tests before being added. Every additional service needs a clear owner for its data, an authentication boundary and an observable failure state.
Choose Open5GS or public VectorCore
Both Open5GS and VectorCore have public source. This guide offers an Open5GS package-based path and a separate VectorCore source-build path. Choose one core path for the initial lab and follow its configuration and subscriber model consistently. Do not start competing MME or gateway services on the same listeners and assume the phone will select the intended one.
The public VectorCore organisation includes mobile core and service repositories, including MME, HSS and SMSC projects. Their documentation is the starting point for inspecting and building published VectorCore software. The VectorCore HSS documentation describes LTE and IMS interfaces including S6a, Cx, Gx and Rx. This makes it a real public option to evaluate, with its own build, database and configuration requirements.
The production SSH inspection did not prove that each running binary exactly matches a particular public commit, release or example configuration. Local service units and integration applications also form part of a deployed system. Record the commits you build, verify configuration against those commits and distinguish an upstream capability from a feature you have tested in your own deployment.
You can learn the essential boundaries with one Ubuntu PC holding separate lab processes or virtual machines if it has adequate resources. Keep the core and radio on the private LAN for the main build. No remote backhaul tunnel is required for that arrangement. Add physical separation, a remote gateway or redundancy when your topology, recovery needs or capacity justify it.
The first milestone is an authorised radio, a test SIM that authenticates, a phone that receives an address and controlled data connectivity that survives a restart. Add a second subscription, protected administration, backup and recovery, and measured service behaviour. Voice and messaging follow that foundation with either core choice.
What this inspection does and does not establish
Verified facts in this chapter came from operating system information, active service inventory, actual executable versions and selected configuration structure. The inspection was read-only. It did not restart services, alter firewall rules, change subscriber records or place calls. Public documentation supplied the explanation of each standard role.
Statements about the intended flow of a complete deployment are architectural explanations. Where multiple implementations were active, the selected production path remains unverified by this inspection. Module presence establishes that a capability is configured or available; a controlled test is still needed to prove its behaviour.
The production service names and version snapshot help explain Lodestar's story on the inspection date. They are not a security certification, a compatibility guarantee for arbitrary phones or a promise that the public tutorial recreates every service. Keep your own evidence sheet with software versions, handset details, test results and the date of each successful recovery exercise.