IC-7610 Remote Access — System Architecture

This document describes how we built a system to remotely operate an Icom IC-7610 HF transceiver from any web browser, bypassing carrier-grade NAT (CGNAT) with a WireGuard tunnel through an Oracle Cloud free-tier VM.

The browser-based interface is powered by icom-lan, an open-source project by Sergey Morozik (KN4KYD) that provides full radio control, spectrum/waterfall display, and audio streaming directly in the browser — no software installation required on the remote user's end.

This is a real, working system — not a theoretical design. Everything here has been tested and verified.

The Problem

The IC-7610 sits on a home LAN behind a T-Mobile 5G gateway, which uses CGNAT. This means:

• No public IP address at the home location
• No ability to port-forward inbound connections to the radio
• Traditional DDNS solutions don't work behind CGNAT

We need remote operators to control the radio from a web browser with no VPN or special software on their end.

The Solution

How It Works

Overview

The system is built around icom-lan, an open-source radio control server created by Sergey Morozik (KN4KYD). icom-lan speaks the Icom radio's native UDP protocol and translates it into a modern web interface with WebSocket-based real-time updates. It provides the full user experience: spectrum/waterfall display, radio controls, metering, and audio streaming — all in the browser.

On our system, the icom-lan backend runs on the Oracle VM and communicates with the IC-7610 over the WireGuard tunnel. nginx sits in front as an HTTPS reverse proxy. Remote users connect via HTTPS to ww0r.org — they never talk to the radio directly, and no radio ports are exposed to the internet.

The WireGuard Tunnel

The key insight is that the EdgeRouter initiates the tunnel outbound to the Oracle VM. Outbound UDP connections work fine through CGNAT — it's only inbound that's blocked. WireGuard's persistent-keepalive (set to 25 seconds) keeps the NAT mapping alive so the Oracle VM can send packets back through the tunnel at any time.

Packet Flow (Browser → Radio)

1. Remote user opens https://ww0r.org/app in their browser
2. nginx terminates HTTPS and proxies the request to icom-lan on localhost:8080
3. The browser establishes three WebSocket connections to the backend:
   • /api/v1/ws — control commands, status updates, meters
   • /api/v1/audio — audio RX/TX streaming
   • /api/v1/scope — spectrum/waterfall data
4. When the user tunes the radio, the browser sends a JSON command over the control WebSocket
5. icom-lan translates it into a CI-V binary command and sends it to the radio via UDP 50002 through the WireGuard tunnel
6. The radio processes the command and sends status/audio/scope data back via UDP
7. icom-lan receives the response and pushes it to the browser over the appropriate WebSocket

Packet Flow (Radio → Browser)

1. IC-7610 sends audio/scope/status data via UDP to the icom-lan backend (via the tunnel)
2. icom-lan processes the data (decodes CI-V, frames audio with headers, parses scope frames)
3. Data is pushed to all connected browsers over WebSocket
4. The browser renders the spectrum/waterfall, plays audio through Web Audio API, and updates the UI

Access Control

The system uses a two-tier access model:

Unauthenticated users connect freely and can listen and tune. Transmit commands (PTT) are blocked server-side — the backend checks for a valid auth token before allowing any transmit operation. This lets anyone explore the bands while protecting against unauthorized transmission.

Oracle Cloud VM Configuration

OCI Infrastructure

• Instance: VM.Standard.E2.1.Micro (Always Free tier)
• OS: Ubuntu 22.04
• Public IP: Reserved (static) — survives reboots
• VNIC: Source/destination check disabled (required for tunnel routing)

OCI Security List (Firewall)

System Services

WireGuard Config (wg0.conf)

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
MTU = 1380
PrivateKey = (hidden)

# NAT for traffic leaving to the internet
PostUp   = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
# NAT for traffic entering the tunnel
PostUp   = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
# Allow forwarding through the tunnel
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp   = iptables -A FORWARD -o wg0 -j ACCEPT
# (matching PostDown rules to clean up)

[Peer]
PublicKey = (EdgeRouter's public key)
AllowedIPs = 10.10.0.2/32, 192.168.1.0/24
PersistentKeepalive = 25

icom-lan Service

[Unit]
Description=icom-lan Web UI
After=network.target wg-quick@wg0.service

[Service]
Type=simple
ExecStart=/opt/icom-lan/.venv/bin/icom-lan \
    --host 192.168.1.40 --control-port 50001 \
    --user guest --pass (hidden) \
    web --host 127.0.0.1 --port 8080 \
    --static-dir /opt/icom-lan/frontend/dist \
    --auth-token (hidden)
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

The backend listens only on 127.0.0.1:8080 — it is not directly accessible from the internet. nginx handles HTTPS termination and proxies requests to it.

EdgeRouter Configuration

WireGuard (EdgeOS CLI)

interfaces {
    wireguard wg0 {
        address 10.10.0.2/24
        listen-port 51820
        mtu 1380
        private-key (hidden)
        peer (Oracle VM's public key) {
            allowed-ips 10.10.0.1/32
            endpoint 129.146.84.173:51820
            persistent-keepalive 25
        }
    }
}

protocols {
    static {
        route 10.10.0.0/24 {
            next-hop-interface wg0
        }
    }
}

Boot Resilience

EdgeRouter's WireGuard interface and static route can silently disappear after reboot if the WAN interface isn't ready during initialization. A task-scheduler script runs every 5 minutes to verify and re-apply if needed:

system {
    task-scheduler {
        task check-wg {
            executable {
                path /config/scripts/check-wg.sh
            }
            interval 5m
        }
    }
}

The script checks if wg0 exists and the static route is present, re-creating them if missing.

Audio Pipeline

Audio flows through several stages from the radio to the browser speaker:

1. IC-7610 sends 16-bit PCM audio at 24kHz over UDP port 50003
2. icom-lan backend receives the raw PCM, adds an 8-byte binary header (codec, sample rate, sequence number), and streams it over a dedicated WebSocket (/api/v1/audio)
3. Browser decodes the frame, converts PCM16 samples to Float32 (divide by 32768.0), creates a Web Audio API AudioBuffer, and schedules gapless playback through a GainNode to the speakers

TX Audio (Browser Mic → Radio)

Transmit audio flows in the reverse direction:

1. Browser captures microphone audio via getUserMedia, encodes it as Opus, and sends binary frames over the /api/v1/audio WebSocket
2. icom-lan backend decodes Opus to PCM at the radio's negotiated sample rate and pushes it to the radio via UDP port 50003
3. IC-7610 modulates the PCM audio and transmits

IC-7610 Radio Settings for TX

The radio must be configured to accept audio from the LAN connection:

MTU Considerations

WireGuard adds ~60 bytes of overhead per packet. With OCI's networking layer adding its own encapsulation, the default MTU of 1420 caused audio packet fragmentation.

Setting MTU = 1380 on both ends of the tunnel resolved this. The MTU must match — a mismatch between the two ends causes fragmentation on one side.

Pitfalls and Lessons Learned

1. OCI's three firewalls — Security list, VNIC source/destination check, and iptables must all allow traffic. This is the #1 cause of silent failures on OCI.
2. OCI default iptables — Oracle's Ubuntu image ships with REJECT rules in INPUT and FORWARD chains. WireGuard PostUp rules that append (-A) land after the REJECT and never match. Remove the REJECT rules before starting WireGuard.
3. MASQUERADE on wg0 — Without this, the icom-lan backend's UDP packets to the radio have a source of 10.10.0.1, but the radio's reply goes out the WAN instead of back through the tunnel. MASQUERADE ensures return traffic flows correctly.
4. MTU mismatch — Must be identical on both tunnel endpoints. A mismatch causes fragmentation visible as garbled audio but working pings.
5. EdgeOS route-allowed-ips — This setting conflicts with the default route on EdgeRouter. Use an explicit static route instead.
6. EdgeOS reboot fragility — WireGuard config can silently disappear after reboot. A scheduled check script is essential.
7. Ephemeral IP — Oracle Free Tier VMs get an ephemeral public IP by default. Reserve it (free, limit 1) or it changes on reboot.
8. CGNAT keepalive — T-Mobile's CGNAT has an aggressive UDP timeout. 25-second persistent-keepalive works, but if the tunnel drops intermittently, try 15 seconds.
9. Browser audio resampling — The Web Audio API resamples to its native rate (usually 48kHz). Aggressive ratios like 3x (16→48kHz) cause intersample peak clipping on loud signals. Use a rate that divides evenly into 48kHz (e.g., 24kHz).
10. IC-7610 spectrum mode — The radio's scope must be in Center mode (not Fixed Edge) for the spectrum display to track frequency changes in the web UI.
11. icom-lan frontend builds — The Oracle free-tier VM has only 1 GB RAM, which is not enough for npm run build. Build the frontend on a local machine and upload the dist/ folder.
12. Python version — icom-lan requires Python 3.11+. Ubuntu 22.04 ships with 3.10 — install 3.11 via the deadsnakes PPA.

Cost

This entire system runs for free:

• Oracle Cloud VM: Always Free tier (no time limit, no credit card charges)
• HTTPS certificate: Let's Encrypt (free, auto-renewing)
• Domain name: ~$10/year (the only cost)
• WireGuard: Open source, built into Linux kernel and EdgeOS
• icom-lan: Open source

Tools and Credits

Built by WW0R. System designed and implemented with assistance from Claude (Anthropic). Last updated: March 2026.