Private APN and IPsec MDM connectivity

Use this guide when an RC500 has cellular service and a private SIM address but remains offline or has an old Last seen time in Telisky MDM.

This is normally an upstream network design, not an IPsec tunnel configured on the RC500. The carrier or private-APN provider carries the SIM subnet through IPsec to the customer edge. The customer firewall must then give that subnet controlled outbound access to Telisky services.

Caution

The Services → IPsec page creates a tunnel that terminates on the RC500. That is a different feature. Do not configure device-side IPsec merely because the SIM provider delivers a private APN through a carrier-to-customer IPsec tunnel.

Before you begin

This guide assumes the carrier-to-customer IPsec service already exists. Obtain these deployment-specific values from the carrier and customer network team:

• Private SIM/APN source subnet or subnets.
• Customer-side IPsec peer, tunnel interface or zone, and traffic selectors.
• Internet egress interface and source-NAT policy.
• DNS and NTP services configured on the deployed RC500s.
• Carrier path-MTU or encapsulation details, when available.

The IPsec termination and internet firewall may be separate systems or functions on the same appliance. The required packet flow is the same in either design. IKE proposals, credentials, lifetimes, and other tunnel-build parameters come from the private-APN provider; they are not configured on the RC500 for this design.

Reference topology

The RC500 initiates every MDM connection. The upstream IPsec tunnel terminates at the customer edge before internet breakout; IPsec termination and firewall functions may run on the same appliance.

All four conditions below must be true:

1. Route: the private SIM/APN subnet reaches the customer IPsec termination.
2. Allow: the customer firewall permits the required destination FQDNs and ports.
3. Resolve and synchronize: the RC500 can use DNS and obtain correct time for TLS validation.
4. NAT and return: the customer edge provides source NAT, internet routing, and stateful return traffic.

A firewall allow rule alone is not sufficient. If the private-APN subnet has no internet route or source NAT after IPsec decryption, the RC500 will remain offline in MDM.

Required outbound access

Create rules from the RC500 private-APN/SIM subnet, not from the router’s LAN subnet.

Core MDM channel

Destination	Protocol and port	Requirement	Purpose
ingest-mqtt.telisky.com	TCP 8883	Required	Primary TLS MQTT check-in, telemetry, configuration, jobs, and command channel

Outbound TCP 8883 is essential. Allowing HTTPS alone does not bring the router online in MDM.

HTTPS services

Destination	Protocol and port	When needed
mdm-api.telisky.com	TCP 443	Device attachment and enrollment API
mdm.telisky.com	TCP 443	MDM-hosted device and firmware services
cloud.telisky.com	TCP 443	Telisky cloud and approved firmware services
fleet.telisky.com	TCP 443	Fleet and approved firmware services
discovery.telisky.com	TCP 443	Remote-support tunnel discovery, when that feature is used

Permit the HTTPS rows used by the deployment lifecycle and enabled features. A network team may allow all listed Telisky HTTPS destinations as one managed service group; discovery.telisky.com is unnecessary when remote-support discovery is not used.

Use FQDN-based destination objects. Do not hard-code the current resolved IP addresses: Telisky services may use Cloudflare or other infrastructure whose addresses can change.

DNS and time

Service	Protocol and port	Current RC500 default	Alternative
DNS	UDP and TCP 53	8.8.8.8 and 1.1.1.1	Configure and permit customer DNS resolvers that can resolve public Telisky names
NTP	UDP 123	0.openwrt.pool.ntp.org through 3.openwrt.pool.ntp.org	Configure and permit a reachable customer NTP service

Permit DNS over both UDP and TCP. TCP is used for large responses and fallback. Correct time is required before normal TLS certificate validation can succeed.

Note

If the deployment overrides the router’s broker, DNS, NTP, enrollment, or firmware destinations, permit the deployed values instead of relying only on the defaults above.

Firewall and security policy

Configure the customer edge with these properties:

• Stateful outbound policy: allow replies to sessions initiated by the RC500.
• Source NAT: translate the private SIM/APN source when it exits to the public internet.
• Direct TLS: bypass HTTPS/TLS inspection for the Telisky FQDNs. The RC500 does not trust a certificate substituted by a customer firewall.
• Direct MQTT: permit TCP 8883 directly. MQTT is not HTTP and cannot use a normal explicit web proxy.
• FQDN refresh: ensure the firewall refreshes DNS-backed address objects when records change.
• No inbound exposure: normal MDM operation requires no unsolicited inbound connection to the RC500.
• Stable sessions: avoid unusually short TCP timeouts. The default MQTT keepalive is 60 seconds.

A practical vendor-neutral policy is:

Source zone:         Private APN / IPsec
Source addresses:    <RC500-SIM-SUBNETS>
Destination objects: ingest-mqtt.telisky.com
Service:             TCP/8883
Action:              Allow, stateful, no TLS inspection
Source NAT:          Enabled at internet egress

Source zone:         Private APN / IPsec
Source addresses:    <RC500-SIM-SUBNETS>
Destination objects: mdm-api.telisky.com
                     mdm.telisky.com
                     cloud.telisky.com
                     fleet.telisky.com
                     discovery.telisky.com
Service:             TCP/443
Action:              Allow, stateful, no TLS inspection
Source NAT:          Enabled at internet egress

Source zone:         Private APN / IPsec
Source addresses:    <RC500-SIM-SUBNETS>
Destination:         Approved DNS and NTP services
Services:            UDP+TCP/53, UDP/123
Action:              Allow, stateful

IPsec routing options

Full-tunnel internet breakout

Use this when all private-APN traffic is expected to exit through the customer network.

• The carrier routes the complete SIM/APN subnet through IPsec.
• The customer edge routes decrypted traffic toward its normal internet firewall.
• The internet firewall applies the FQDN policy and source NAT.
• Return traffic is restored by the NAT state and routed back into the APN/IPsec path.

Restricted service breakout

Use this when the private APN should reach only approved services.

• Route only approved Telisky, DNS, and NTP traffic from the decrypted APN zone to internet egress.
• Deny other internet destinations from that zone.
• Preserve direct TCP connectivity; do not force MQTT through an HTTP proxy.
• Keep FQDN objects and resolver access current.

Air-gapped private APN

A private APN with no internet breakout cannot connect to cloud MDM. The cellular session and upstream IPsec tunnel may both be healthy while the router remains offline in the portal.

MTU and MSS

IPsec adds encapsulation overhead. A route may pass ping and complete a TCP handshake while larger TLS packets stall or fragment.

At the IPsec termination or customer firewall:

• Allow useful ICMP fragmentation feedback where policy permits.
• Derive the effective path MTU from the carrier and IPsec encapsulation.
• Apply TCP MSS clamping to the derived value if the platform does not handle path-MTU discovery reliably.
• Do not copy an arbitrary MSS from another deployment; tunnel modes, carriers, and encapsulation differ.

Suspect MTU/MSS when TCP 8883 connects but the TLS handshake stalls, connections repeatedly reset under load, or small requests work while firmware downloads fail.

MDM versus direct Local WebUI access

Cloud check-in is outbound. Browsing directly to the router's private SIM address is a separate, optional inbound management flow.

For normal MDM connectivity, do not open inbound TCP 443 to the router.

If authorized administrators must browse directly to a router’s private SIM address, configure Remote WebUI access separately. It remains disabled by default and permits only HTTPS TCP 443 from explicit canonical source CIDRs.

Ordered setup checklist

Complete these in order. Testing later steps before earlier steps are correct can hide the actual failure.

1. Record the assigned networks. Obtain the private SIM/APN subnet, customer-side tunnel interface, and public egress interface.
2. Confirm IPsec selectors. The carrier and customer encryption domains must include every assigned SIM subnet in the correct direction.
3. Confirm the decrypted route. The customer edge must route the APN subnet from IPsec toward the intended internet firewall or service-breakout policy.
4. Configure DNS. Permit the RC500’s configured resolver and verify it resolves ingest-mqtt.telisky.com.
5. Configure time. Permit the configured NTP service and verify the router obtains a current clock.
6. Create FQDN firewall objects. Add the Telisky names from the tables above; do not convert them into permanent IP objects.
7. Allow MDM traffic. Permit TCP 8883 to the core broker and TCP 443 to the HTTPS destinations required by the deployment lifecycle and enabled features. Apply the rules to the private-APN source zone and subnet.
8. Bypass TLS inspection. Exclude the Telisky FQDNs from certificate substitution or decryption policy.
9. Enable source NAT. Apply NAT when the private APN exits to the public internet.
10. Check MTU/MSS. Validate the effective tunnel MTU and clamp TCP MSS if required.
11. Test one router. Prove one known SIM address before applying the policy to the full APN range.
12. Confirm MDM state. Check that Last seen advances and the router becomes online in the correct organization.

Verification sequence

Use firewall session logs or packet capture at the customer edge. Do not capture or publish customer payloads.

1. Confirm traffic arrives from IPsec

Look for packets whose source is the test router’s private SIM address. If no packets arrive, check the carrier APN, IPsec security associations, traffic selectors, and the return route before changing MDM rules.

2. Confirm DNS

Verify the router’s configured resolver receives queries and returns addresses for:

ingest-mqtt.telisky.com
mdm-api.telisky.com
mdm.telisky.com

A lookup from an administrator’s workstation is not sufficient if the RC500 uses different resolvers or policy.

3. Confirm time

Verify UDP 123 leaves the APN zone and receives a reply. A severely incorrect clock commonly appears as a TLS or certificate failure rather than an NTP error.

4. Confirm MQTT

Look for an established stateful session:

<RC500-private-SIM-IP>:<ephemeral-port>
  → ingest-mqtt.telisky.com:8883

The session should remain established or reconnect normally. Repeated SYNs without a SYN-ACK indicate routing or firewall failure. A completed TCP handshake followed by TLS alerts points to inspection, time, certificate, or MTU problems.

5. Confirm HTTPS

During attachment, firmware, or remote-support operations, verify direct TCP 443 sessions to the applicable FQDNs. Do not require HTTPS activity continuously; MQTT is the normal persistent MDM channel.

6. Confirm the portal

In Telisky MDM:

• Open the correct organization.
• Find the router by its approved inventory identifier.
• Confirm Last seen advances.
• Confirm the router changes to online after fresh MQTT contact.
• Run a low-risk status refresh before attempting a configuration or firmware job.

Symptom guide

Symptom	Most likely area	Check next
Cellular is connected, but no APN traffic reaches the customer edge	Carrier/APN or IPsec selectors	SIM subnet assignment, IPsec SA, encryption domains, carrier routing
APN traffic reaches the firewall, but no internet session is created	Routing or policy	Decrypted route, security zone, FQDN rule match, default/service route
TCP 8883 is allowed, but the source is private on the internet edge	NAT	Source-NAT rule order and egress interface
DNS queries time out	Resolver policy	UDP/TCP 53, configured resolver, return route
TCP connects, then TLS immediately fails	Time or TLS inspection	NTP, device clock, certificate-substitution policy
TLS starts but stalls or repeatedly resets	MTU/MSS	Path MTU, fragmentation feedback, MSS clamp
HTTPS works, but the router remains offline	MQTT blocked	ingest-mqtt.telisky.com TCP 8883
MDM works, but browsing to the private SIM IP fails	Separate inbound policy	Private-APN route plus Services → Remote WebUI source allowlist
Router appears under the wrong customer/site	MDM assignment	Organization and device attachment, not IPsec routing

Copy-and-paste request for a network team

Subject: RC500 private APN/IPsec requirements for Telisky MDM

Please provide controlled outbound internet egress for the RC500 private
SIM/APN subnet after it is decrypted at the customer-side IPsec termination.

Required routing and security behavior:
- Route the complete RC500 SIM/APN subnet from the IPsec zone to the internet
  egress policy.
- Apply source NAT at internet egress.
- Permit stateful return traffic for connections initiated by the RC500.
- Use FQDN-based destination objects; do not pin current destination IPs.
- Bypass TLS/SSL inspection for the Telisky destinations.
- Do not send MQTT through an HTTP proxy.

Required core service:
- TCP 8883 to ingest-mqtt.telisky.com

Required/feature-dependent HTTPS services:
- TCP 443 to mdm-api.telisky.com
- TCP 443 to mdm.telisky.com
- TCP 443 to cloud.telisky.com
- TCP 443 to fleet.telisky.com
- TCP 443 to discovery.telisky.com when remote-support discovery is used

Infrastructure services:
- UDP and TCP 53 to the RC500's configured DNS resolvers
- UDP 123 to the RC500's configured NTP servers

Please validate the tunnel path MTU and apply an appropriate TCP MSS clamp if
path-MTU discovery does not work through the IPsec service.

No unsolicited inbound port to the RC500 is required for normal MDM operation.
Direct Local WebUI access is a separate policy and should not be enabled as part
of this MDM egress request.

Test SIM/APN subnet: <SUBNET>
Customer IPsec zone/interface: <ZONE_OR_INTERFACE>
Internet egress interface: <INTERFACE>
Customer change/ticket reference: <REFERENCE>

Information to collect before contacting support

• Customer or site name.
• Private APN name and carrier.
• Private SIM subnet; redact individual SIM identifiers unless requested securely.
• Whether the carrier-to-customer IPsec SA is established.
• Customer firewall vendor and software version.
• Whether the design uses full-tunnel or restricted service breakout.
• DNS and NTP services assigned to the routers.
• Sanitized firewall decision logs for one test SIM address and the required ports.
• Time and time zone of the test.
• Whether TCP 8883 establishes and whether TLS inspection is bypassed.
• Effective tunnel MTU or configured MSS clamp, if applicable.

Do not send passwords, pre-shared keys, private keys, tokens, full SIM identifiers, packet payloads, or unredacted customer traffic in a support request.