MDD Sim Gateway: a self-hosted SIM/eSIM gateway for VoWiFi, SMS and per-country egress

What MDD Sim Gateway solves, and for whom

A SIM card is a credential locked inside a carrier's device policy. MDD Sim Gateway moves the useful parts of that credential onto hardware you own: an ARM64 board, a cellular module or a USB PC/SC reader, and a browser session. The README describes the target as Debian, Ubuntu or Armbian ARM64 devices, and the repository layout (engine/, control/, webui/, host/, install.sh) matches that single-host model rather than a distributed service.

The problem it addresses is fragmentation. A modem exposes AT commands, a reader exposes PC/SC, an eUICC needs an LPA, IMS needs EAP-AKA and IMS-AKA, and the resulting traffic needs a route that does not leak. The project pulls those into one console with Chinese and English interfaces, and it manages cellular modules, PC/SC readers and eUICC profiles through ModemManager and lpac respectively.

It is for someone who holds the line personally. The README states the software is intended for the verified owner of the number, within what the carrier explicitly permits, and caps the system at five SIM lines. It is not a platform for reselling access, and the README says so in the same paragraph that describes the cap.

How the AKA, IMS and routing pieces fit together

The distinguishing design choice is where authentication happens. EAP-AKA and IMS-AKA run inside the physical SIM or eUICC. The README states the project does not read, store or use Ki/OP/OPc, and provides no software Milenage path, so the AKA keys never leave the card. That is the reason a PC/SC reader can serve VoWiFi without the host ever holding the long-term secret.

State is tracked per module rather than globally. Each physical module keeps independent desired states for 4G, airplane mode and VoWiFi: the 4G toggle controls only the mobile data bearer, airplane mode controls the radio, and VoWiFi starts and stops on its own, with each state read from its own ModemManager object. Multi-module 4G uses separate ModemManager objects, NetworkManager connections and bearers.

Routing is the other half. Country exits are built from a proxy library of subscriptions, concrete nodes or SOCKS5 entries. Reality/XHTTP nodes are handled by an Xray-core compatibility layer on the local loopback, with no LAN-facing port; other nodes and the per-country TUN are managed by sing-box. Each country gets its own TUN such as `mdd-jp`, and only that SIM's ePDG route enters it. Because IKEv2/ESP NAT traversal depends on UDP 500/4500, the system validates UDP capability on every non-direct exit and, per the README, fails closed per SIM rather than leaking to the wrong country.

There is one carrier-specific exception worth noting. DITO Telecommunity (515-66) uses the AES-CBC-128/HMAC-SHA1/MODP-1024 IKE suite that its ePDG publishes; that older suite applies only to that PLMN, while other carriers continue on the existing MODP-2048 suite. The project also responds to EAP-AKA permanent and full identity requests per RFC 4187, which the README frames as compatibility for carriers that require that identity flow.

Installing on ARM64 and reaching the console

The README recommends a Debian, Ubuntu or Armbian ARM64 host with systemd, Docker, USB and a stable network. Before starting, the root filesystem needs at least 2 GiB free; the README suggests an 8 GB or larger system disk and roughly 3 GiB free before an upgrade so a new image and one rollback generation fit side by side. The stated measured footprint is a 607 MB engine image, about 676 MB for two generations sharing a base layer, and about 102 MB for the source checkout and virtual environment, with an extra 355 MB for Docker control-plane mode.

The installer clones the repository and runs the install path:

git clone https://github.com/MddIdd/mdd-sim-gateway.git
cd mdd-sim-gateway
sudo ./install.sh install

According to the README, the installer reuses an existing system Docker if present and only installs from the distribution when there is none, installs pcscd plus ModemManager/NetworkManager, downloads sing-box 1.13.15 and Xray-core 26.3.27 for the architecture and verifies their SHA-256, downloads the pinned lpac 2.3.0 source and builds it locally, builds the control plane, WebUI and per-SIM VoWiFi engine, then installs systemd services with boot startup. It checks rootless mode, port conflicts and container ownership, and only manages containers carrying an MDD marker; an existing Docker is not upgraded, reconfigured or cleaned up.

After installation the console is at `https://<gateway address>:8443`. The README instructs creating the administrator account immediately, from a trusted LAN or VPN. Day-to-day operations use the same script:

sudo ./install.sh status
sudo ./install.sh logs
sudo ./install.sh reload
sudo ./install.sh build-lpac
sudo ./install.sh uninstall

One hardware note from the README: the Sandtech SCR Prime (`04d9:c001`) is verified on real hardware by the project and uses the `patchprime` driver patch during installation. That wording matters. The hardware table's checkmarks mean the system has a technical path, not that every SIM, firmware or carrier will allow it through.

Where the design constrains you

The five-line cap is the first hard boundary. The README states the system stores and runs at most five SIM lines and does not offer independent SIP accounts or Telegram-based dialing, SMS sending or hangup. If your plan was to point a softphone at a SIP trunk, this is the wrong project; browser softphone, SMS, call records, missed-call notification and per-line local voicemail are the intended surface, and recordings stay on the gateway rather than travelling with notifications or support bundles.

Telegram is one-way by design: incoming calls, SMS and device status notifications only, with no remote control commands accepted. Anyone expecting a chat bot to place or answer calls will be disappointed, and that restriction is deliberate rather than a missing feature.

Carrier admission is outside the project's control. The README repeats that whether a carrier opens Wi-Fi Calling still depends on the plan, region, device identity and network policy. A working install can therefore still produce a gateway that never registers IMS for a given line.

Storage is a quieter constraint. Explicit source builds are called out as an exception: compiling Asterisk on the device needs several additional GiB of build cache and intermediate artifacts, unrelated to the measured image numbers, and the README says that path is unsuitable for space-constrained devices. Normal installs and upgrades download CI-built images and never take that route. Virtual machines have their own trap: enlarging the virtual disk is not enough, the root partition and filesystem must be extended too, and `df -h /` is the authority.

Compared with a carrier-locked GSM gateway box

The related search terms around this project cluster on hardware gateways: GSM gateway, SIM card GSM gateway, multi-SIM GSM gateway, and named models such as Dinstar and Grandstream. Those are appliances. A typical GSM gateway presents a SIP interface so an existing PBX can route calls through inserted SIMs, and the vendor owns the firmware, the channel count and the feature list.

MDD Sim Gateway inverts that. There is no SIP trunk exposed to your PBX, and the README explicitly does not provide independent SIP accounts. Instead the control surface is a web console with a browser softphone, and the interesting capability is not call routing but the combination of VoWiFi over EAP-AKA inside the card, eUICC profile management via lpac, and per-country TUN egress with UDP validation. A Dinstar-class box does not attempt the egress isolation problem, and it does not manage eSIM profiles.

The trade is operational. An appliance arrives configured; this project expects you to supply an ARM64 host, a supported module or reader, and the patience for ModemManager and PC/SC behaviour. It also inherits upstream lineage: the README credits pagecat/vowifi_gateway (MIT) as the upstream basis for the VoWiFi engine and the overall management/engine/WebUI architecture, with 4G data and SMS, per-country egress routing, unified device management, failover and the test system added on top. If you want a SIP-facing multi-channel box, buy one. If you want a card-controlled gateway with regional egress, this is a different category.

Updates, licence and what maintenance costs you

The repository was last pushed on 2026-09-15, and v1.9.5 was released the same day, following v1.9.4 on 2026-09-12 and v1.9.3 on 2026-09-11. The README describes a background check for new versions every 6 hours, with a choice between automatic updates and notification only. Two follow modes exist: all versions tracks the latest approved Release, while major-only tracks a separately configured stable major version, and the README notes that a patch can still be installed onto that major even when a newer patch exists. Unattended installation requires `update-policy.json` to explicitly permit the specific version and the earliest execution time, which is a consent file rather than a schedule, and it is the thing to inspect first if you plan to let updates run without a human.

The licence is GPL-3.0-only. The README points to THIRD_PARTY_LICENSES.md and NOTICE for the upstream components, which retain their own licences; those include MIT-licensed code from pagecat/vowifi_gateway, sing-box, lpac, pyscard and others. If you intend to redistribute a modified build or ship it inside a product, the copyleft obligations of GPL-3.0-only apply to the combined work, and the third-party notices still need to travel with it. That is a description of the stated licensing, not legal advice; take it to counsel if redistribution is on the table.

Operationally, the upgrade cost is disk, not downtime: the README's guidance to keep roughly 3 GiB free before an upgrade exists so a new image and one rollback generation coexist. Budget that headroom permanently rather than clearing space at upgrade time.

Editorial conclusion

Adopt MDD Sim Gateway if you hold the SIMs yourself, run ARM64 Debian, Ubuntu or Armbian, and want VoWiFi, SMS and per-country egress under one console without exposing Ki/OP/OPc. Do not adopt it if you need more than five lines, want an independent SIP client, or expect a Telegram bot to place calls. Before installing, confirm on the hardware page that your modem or PC/SC reader is listed, check that your carrier permits Wi-Fi Calling on your plan, and read docs/INSTALL.md for the 2 GiB free-space requirement and the update-policy.json consent model.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MddIdd/mdd-sim-gateway on GitHub
4. README
5. Releases