A hotspot behind NAT, on Wi-Fi and on the road: do you need port forwarding and LTE

"I set up a hotspot — do I need to forward something on the router? My ISP gives me a private IP after all…" — this is probably the single most common beginner's question. The good news: in the vast majority of cases you don't need to forward anything. An MMDVM hotspot calls the master server itself — it opens an outbound connection rather than waiting for an inbound one. That's why it happily works behind home NAT, on mobile internet, on hotel Wi-Fi and from a car over an LTE modem. In this article we'll cover why it works this way, when problems do crop up after all (CGNAT, blocking, firewalls), how to power a hotspot on the road, and what to do if it "won't connect".

Why port forwarding is usually unnecessary

To grasp the logic, you need to know who calls whom. A hotspot running Pi-Star/MMDVMHost firmware connects to the network (BrandMeister, our DMRhub master, an XLX reflector) using the Homebrew/MMDVM protocol over UDP. The hotspot is always the initiator: it sends a login packet (RPTL) out to the master's address and port, authenticates, and from then on the "channel" is kept alive by periodic keep-alives — a ping/pong exchange in both directions.

When your hotspot sends a UDP packet out to the internet, the router records this in its address translation table (NAT/conntrack) and automatically returns the replies that come back from the same address. This is the same mechanism that opens websites in your browser without any forwarding. Therefore:

• A private/"home" IP behind NAT — that's fine. An outbound connection doesn't need a public address.
• Guest Wi-Fi at a friend's place, at work, in a hotel — usually works, as long as UDP is allowed outbound.
• Mobile internet (LTE/4G/5G) — works, even though cellular carriers almost always use CGNAT (more on that below).

Which ports are involved

These are outbound ports on the hotspot's side — that is, the "from home to the internet" direction. You don't need to open them manually; NAT passes them through anyway. It's useful to know them for diagnostics and in case of a strict corporate firewall:

CGNAT and "symmetric" NAT: when theory meets your carrier

The most common scare story is CGNAT (Carrier-Grade NAT). That's when the carrier hides thousands of subscribers behind a single public IP — typical of mobile internet and some home ISPs. CGNAT adds yet another layer of translation between you and the network and breaks inbound port forwarding (you physically can't open a port "to yourself").

But our hotspot doesn't need inbound forwarding at all! For outbound UDP, CGNAT is almost never an obstacle: the packet leaves, the carrier holds the translation, the replies come back. So a hotspot behind CGNAT usually connects to the master just fine. There are still a few subtle spots:

• Short translation time-outs. Some carriers quickly "forget" a UDP session with no traffic. Because of this the link may occasionally drop and reconnect. It's cured by the fact that Pi-Star sends keep-alives anyway — the session usually survives.
• Symmetric NAT. For a simple "client → server" it's no obstacle: the master replies from the same address and port the login arrived at. Symmetric NAT problems concern P2P/STUN scenarios, not our client-server scheme.
• Double NAT at home. If a router sits behind a router (for example, your Wi-Fi router behind the ISP's router) — for outbound UDP that's no problem either. But if you did need inbound forwarding, double NAT would kill it.

A hotspot on mobile internet: LTE modem and smartphone

Since inbound forwarding isn't needed, a hotspot easily gets on the air wherever there's only cellular coverage — at the cottage, on a trip, in the car. There are two working options.

A smartphone as an access point (the simplest)

1. Turn on "Wi-Fi hotspot" (tethering mode) on your phone.
2. Enter the network name (SSID) and password of that hotspot in the hotspot's Wi-Fi settings.
3. Boot the hotspot — it connects to the phone and reaches the master through it.

A USB LTE modem or 4G HAT (more permanent)

For a permanent "mobile" node it's more convenient to plug a USB dongle or a 4G expansion board straight into the single-board computer. The downside is that setting up the modem interface under Linux is a bit harder than just entering a Wi-Fi password. The upside is that your phone stays free and the node is self-contained.

Power on the road: how much a hotspot draws

The main travel advantage of a hotspot is its tiny power draw. A Raspberry Pi Zero (W/2 W) single-board computer with an MMDVM board draws roughly ~100–250 mA at 5 V in operation (on the order of 0.5–1 W on average; peaks during transmit and startup are higher). This means an ordinary power bank keeps the node running for a very long time.

The figures are approximate: a power bank's real output is below its rated capacity (conversion efficiency, self-discharge, voltage sag toward the end), plus Wi-Fi and an LTE modem add to the consumption. But the order of magnitude is clear — this is not a power-hungry device at all.

"The hotspot won't connect": step-by-step diagnostics

If on the Pi-Star dashboard the master is "red" / Disconnected, work through it in order — from simple to complex. In 90% of cases one of four causes is to blame: internet, time/DNS, the master address, power.

1. Is there any internet at all. Open the hotspot's dashboard and check whether it sees the network. The quickest test is to connect the hotspot to a phone in tethering mode: if it works → the problem is in the original network (filtering/blocking), not in the hotspot.
2. Time and DNS. This is a classic trap. A Raspberry Pi has no built-in battery-backed clock (RTC), so after a long stretch offline its time "drifts". And with the wrong time DNSSEC signature validation breaks — the resolver starts treating DNS answers as "stale" and won't hand out an IP. You get a vicious circle: "no time because no DNS, and no DNS because the time is wrong". It's broken by a reboot with internet, a manual NTP sync, or a one-off manual date set.
3. The master's address and code. Check the settings: is the right server (Master) selected, is the correct password/security code entered, along with your callsign and DMR ID. A typo in the code or an old master address = "login rejected".
4. Power. The lightning-bolt icon, spontaneous reboots, loss of Wi-Fi — almost always under-powering (see the block above). Swap the cable and the source for ones you know are good.

# Manually sync the time on Pi-Star (over SSH)
sudo systemctl stop ntp.service
sudo ntpdate pool.ntp.org      # pull in the exact time
sudo systemctl start ntp.service

# If ntpdate isn't in the system (it's been removed on newer builds) —
# set the date manually, then ntp will pull in the exact time itself:
sudo date -s "10 JUN 2026 12:00:00"

# Check connectivity and DNS
ping -c3 dmrhub.ru             # does the master resolve and ping
date                          # is the time correct

When port forwarding is needed after all

To close the topic honestly: inbound forwarding may be needed in rare cases, and they don't concern a hotspot's normal operation:

• Access to the Pi-Star dashboard from outside. If you want to open the hotspot's web UI from the internet (not from the home network) — then you need forwarding/a tunnel. But exposing the admin panel to the outside is insecure; a VPN is better.
• Your own master server. If you're running the network server itself (not a client hotspot) — that one does need a public IP and an open inbound port, because hotspots reach out to it. That's a different role.