Common Tools¶

RansNet routers include several built-in tools for diagnosing network connectivity, performance, and quality issues, and for accessing routers remotely. These tools help troubleshoot end-to-end connectivity, measure link quality (latency and packet loss), test throughput, monitor network performance, and open the router CLI or web GUI from mFusion.

Tool Overview¶

Navigate to Device List, click the yellow Tools button to access the following diagnostic tools:

Tool	Purpose
Ping	Test end-to-end connectivity and measure quality (packet loss, latency)
Traceroute	Display the network path and hop-by-hop latency to a destination
Throughput Test	Measure data transfer rate using iperf3 (requires remote iperf3 server)
Speed Test	Check Internet link speed via cloud-based speed test server
TWAMP	RFC 5357 protocol for active network performance measurement (latency, jitter, packet loss)
tcpdump	Capture and analyze live network packets to troubleshoot packet flow at each hop
Client Flow	See per-client data usage and top destinations in the current 15-minute window (CLI); history on the mFusion Usage tab
Remote SSH	Open the router CLI in a browser terminal through mFusion, with no firewall or port-forwarding changes on site
Remote Web	Open the router web GUI through mFusion (gateway series only)
Upgrade Firmware	Update device firmware
Reboot	Reboot the device

Ping¶

Ping tests end-to-end connectivity and quality metrics (packet loss, latency, jitter).

GUI Usage¶

Click Ping in the tools menu, enter a destination IP address or FQDN, and click Run.

CLI Usage¶

Enter enable mode and use the ping command:

RansNet# ping 1.1.1.1
  source     Source IP-address (ip) or interface (ip and arp)
  repeat     Requests to send count, default is 5
  vrf        Ping source VRF
  resolve    Resolve names
  broadcast  Ping broadcast address
  size       Packet size
  interval   The time interval between packets, default is 1
  flood      Flood ping
  <cr>

Example¶

RansNet# ping 1.1.1.1 source 10.18.18.1
PING 1.1.1.1 (1.1.1.1) from 10.18.18.1: 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=59 time=2.550 ms
64 bytes from 1.1.1.1: seq=1 ttl=59 time=2.176 ms
64 bytes from 1.1.1.1: seq=2 ttl=59 time=2.621 ms
64 bytes from 1.1.1.1: seq=3 ttl=59 time=2.977 ms
64 bytes from 1.1.1.1: seq=4 ttl=59 time=2.683 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 2.176/2.601/2.977 ms
RansNet#

Tip

GUI accepts the same options as CLI. Append options directly in the GUI input field (e.g., 1.1.1.1 source 10.18.18.1).

Traceroute¶

Traceroute displays the network path (hops) to a destination and measures the latency between each hop.

GUI Usage¶

Click Traceroute in the tools menu, enter a destination IP address or FQDN, and click Run.

CLI Usage¶

Enter enable mode and use the traceroute command:

RansNet# traceroute
  ip      IPv4
  ipv6    IPv6
  String  Hostname or IP-address to trace the route

RansNet# traceroute 1.1.1.1
  resolve    Resolve names
  source     Source IP-address
  vrf        Source VRF
  interface  Source interface
  <cr>

Example¶

RansNet# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 15 hops max, 38 byte packets
 1  61.13.198.165  1.146 ms  *  *
 2  10.100.11.245  1.808 ms  1.074 ms  1.291 ms
 3  *  *  *
 4  27.111.230.2  1.781 ms  27.111.228.132  1.916 ms  *
 5  *  *  172.69.117.89  4.951 ms
 6  1.1.1.1  1.639 ms  2.059 ms  *
RansNet#

Note

Hops showing * * * indicate no response (ICMP timeout). This is normal for some intermediate routers.

Speed Test¶

Speed Test measures your Internet link speed by connecting to a cloud-based speed test server (Ookla Speedtest).

GUI Usage¶

Click Speed Test in the tools menu and click Run. The test measures download speed, upload speed, latency, and packet loss.

CLI Usage¶

Use the test speedtest command:

RansNet# test speedtest

   Speedtest by Ookla

     Server: MyRepublic Singapore - Singapore (id = 5935)
        ISP: Sptel
    Latency:     1.46 ms   (0.78 ms jitter)
   Download:   476.84 Mbps (data used: 346.9 MB )
     Upload:   938.77 Mbps (data used: 1.3 GB )
Packet Loss:     0.0%
 Result URL: https://www.speedtest.net/result/c/08aae5ff-8fd8-43b5-a26d-d15ed264bc2f
RansNet#

Warning

The first time you run this test, you will be prompted to accept the Speedtest license agreement. Enter YES to proceed.

Throughput Test¶

Throughput Test measures data transfer rate using iperf3. It requires an iperf3 server running on a remote system (either a cloud iperf3 server or a RansNet router configured as iperf3 server).

For a list of public iperf3 servers, see iperf.fr.

Architecture¶

RansNet routers can act as either iperf3 server (passive measurement) or client (active measurement). In a point-to-point throughput test:

Remote RansNet router: runs as iperf3 server
Local RansNet router: runs as iperf3 client

Step 1: Configure Remote Router as iperf3 Server¶

First, configure the firewall to permit inbound iperf3 traffic:

firewall-input 100 permit all tcp dport 5201

Then start the iperf3 server:

SGNOC-GW1# test server
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

Step 2: Run Throughput Test from Client Router¶

Launch the iperf3 throughput test using the test throughput command:

RansNet# test throughput 118.189.175.164
[info] getting download throughput (server send to client).
Connecting to host 118.189.175.164, port 5201
Reverse mode, remote host 118.189.175.164 is sending
[  4] local 61.13.198.166 port 56496 connected to 118.189.175.164 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  48.0 MBytes   402 Mbits/sec
[  4]   1.00-2.00   sec  46.2 MBytes   388 Mbits/sec
[  4]   2.00-3.00   sec  56.6 MBytes   476 Mbits/sec
[  4]   3.00-4.00   sec  58.7 MBytes   492 Mbits/sec
[  4]   4.00-5.00   sec  57.2 MBytes   480 Mbits/sec
[  4]   5.00-6.00   sec  57.2 MBytes   480 Mbits/sec
[  4]   6.00-7.00   sec  57.2 MBytes   480 Mbits/sec
[  4]   7.00-8.00   sec  57.2 MBytes   480 Mbits/sec
[  4]   8.00-9.00   sec  57.2 MBytes   480 Mbits/sec
[  4]   9.00-10.00  sec  56.9 MBytes   477 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   558 MBytes   468 Mbits/sec  609             sender
[  4]   0.00-10.00  sec   553 MBytes   464 Mbits/sec                  receiver

iperf Done.
[info] getting upload throughput (client send to server).
Connecting to host 118.189.175.164, port 5201
[  4] local 61.13.198.166 port 56574 connected to 118.189.175.164 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  16.1 MBytes   135 Mbits/sec   27    252 KBytes
[  4]   1.00-2.00   sec  15.8 MBytes   133 Mbits/sec    1    221 KBytes
[  4]   2.00-3.00   sec  15.7 MBytes   132 Mbits/sec    5    190 KBytes
[  4]   3.00-4.00   sec  15.5 MBytes   130 Mbits/sec    0    247 KBytes
[  4]   4.00-5.00   sec  15.9 MBytes   134 Mbits/sec    1    220 KBytes
[  4]   5.00-6.00   sec  15.6 MBytes   131 Mbits/sec    6    187 KBytes
[  4]   6.00-7.00   sec  15.9 MBytes   133 Mbits/sec    0    244 KBytes
[  4]   7.00-8.00   sec  16.0 MBytes   134 Mbits/sec   13    204 KBytes
[  4]   8.00-9.00   sec  15.7 MBytes   132 Mbits/sec    0    258 KBytes
[  4]   9.00-10.00  sec  15.6 MBytes   131 Mbits/sec    1    232 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   158 MBytes   132 Mbits/sec   54             sender
[  4]   0.00-10.00  sec   157 MBytes   132 Mbits/sec                  receiver

iperf Done.
RansNet#

TWAMP¶

TWAMP (Two-Way Active Measurement Protocol) is a standards-based protocol defined in RFC 5357 for actively measuring IP network performance metrics (latency, jitter, packet loss) between two endpoints.

RansNet routers can function as either TWAMP server (responder) or client (initiator).

Step 1: Enable TWAMP Server on Remote Router¶

Start the TWAMP server:

SGNOC-GW1# twping server start
Starting twamp-server (via systemctl): twamp-server.service.
SGNOC-GW1#

Configure firewall rules to permit TWAMP traffic:

TCP port 862 (control channel)
UDP ports 18760-19960 (data channels)

firewall-input 200 permit all tcp dport 862
firewall-input 201 permit all udp dport 18760:19960

Server mode options:

# Start server on default port 862
twping server start

# Start on custom port
twping server start port 5000

# Start on specific address
twping server start address 192.168.1.1

# Check server status
twping server status

# Stop server
twping server stop

# Shorthand (start is default)
twping server

Step 2: Run TWAMP Client on Test Router¶

Launch the TWAMP client test:

VM53-Demo-Data1# twping client 118.189.175.164

Session ID: 76bdafa4edbc59aa939ab58df0c46b82
76bdafa4edbc59aa939ab58df0c46b82
Time:       2026-05-24T00:51:55.704 - 2026-05-24T00:52:03.827
Stats:      100 sent, 0 lost (0.000%), 0 send duplicates, 0 reflect duplicates
===================================================================
Direction              Min        Max         Avg      Jitter  Loss
-------------------------------------------------------------------
Send (outbound):     0.0582ms    2.72ms     0.3ms     0.6   0.000%
Reflect (inbound):   0.128ms    2.15ms     0.3ms     0.2   0.000%
Roundtrip:           0.186ms     3.1ms     0.6ms     1.4   0.000%
-------------------------------------------------------------------

VM53-Demo-Data1#

Client mode options:

# Basic client test
twping client 118.189.175.164

# With custom count
twping client 118.189.175.164 repeat 200

# With source IP/interface
twping client 118.189.175.164 source 192.168.1.1

# With authentication
twping client 118.189.175.164 username testuser

# Combined
twping client 118.189.175.164 repeat 200 source eth0 username testuser

tcpdump¶

tcpdump captures live network packets for detailed traffic analysis. Use it to observe packet flows at each hop in the network path and identify where traffic is being dropped or blocked.

RansNet routers include tcpdump pre-installed. Run it on an interface to see live packets:

RansNet# tcpdump interface eth0 port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:10:04.814948 IP 61.13.198.166.59874 > 118.189.175.168.443: Flags [S], seq 2132128584, win 29200, options [mss 1460,sackOK,TS val 73030990 ecr 0,nop,wscale 6], length 0
13:10:04.820498 IP 61.13.198.166.37762 > 118.189.175.168.443: Flags [P.], seq 3045555367:3045555884, ack 3162549609, win 457, length 517
13:10:04.820984 IP 118.189.175.168.443 > 61.13.198.166.59874: Flags [S.], seq 1045307433, ack 2132128585, win 42340, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
13:10:04.824429 IP 61.13.198.166.59874 > 118.189.175.168.443: Flags [.], ack 1, win 457, length 0
13:10:04.824680 IP 61.13.198.166.59874 > 118.189.175.168.443: Flags [F.], seq 1, ack 1, win 457, length 0
13:10:04.824912 IP 61.13.198.166.59874 > 118.189.175.168.443: Flags [R.], seq 2, ack 1, win 457, length 0
13:10:04.828595 IP 118.189.175.168.443 > 61.13.198.166.37762: Flags [.], ack 517, win 83, length 0
13:10:04.898689 IP 61.13.198.166.51570 > 13.204.106.34.443: Flags [.], ack 4108510905, win 251, length 0

CLI Usage¶

RansNet# tcpdump interface eth0 port 443
  host    View output by specific source or destination host
  filter  Filter output by expression (e.g., src 192.168.1.1)
  detail  Display full packet details (header and payload)
  vrf     Run tcpdump within a specific VRF
  <cr>

Example: Troubleshooting Packet Flow¶

When packets aren't reaching their destination, use tcpdump at each hop to identify where they're being dropped or blocked. Follow this decision tree:

flowchart TD
    A["Run tcpdump on incoming interface<br/>(expected source side)"] --> B{"Packets<br/>arriving?"}
    B -->|No| C["Check upstream routing<br/>and accessibility"]
    B -->|Yes| D["Run tcpdump on outgoing interface<br/>(expected destination side)"]
    D --> E{"Packets<br/>leaving?"}
    E -->|No| F["Check:<br/>• Firewall rules permit access?<br/>• Routing table has route<br/>to destination?"]
    E -->|Yes| G{"Receiving<br/>reply packets?"}
    G -->|No| H["Check:<br/>• Firewall rules for return traffic<br/>  (SNAT/translation)?<br/>• Upstream routing has route<br/>  back to source IP?"]
    G -->|Yes| I["Check downstream device<br/>(next-hop router/firewall)<br/>blocking return path"]

    C --> J["Problem found on<br/>upstream path"]
    F --> K["Problem found on<br/>local router"]
    H --> L["Problem found on<br/>upstream path"]
    I --> M["Problem found on<br/>downstream path"]

    style J fill:#ffcccc
    style K fill:#ffcccc
    style L fill:#ffcccc
    style M fill:#ffcccc

Troubleshooting methodology:

Incoming interface — Verify traffic arrives from the source. Use filters (e.g., host 192.168.1.1) to isolate specific flows.
If packets don't arrive, the problem is upstream (check routing and reachability to your router).
Outgoing interface — Verify traffic leaves toward the destination.
If packets don't leave, check local firewall rules and routing table.
Return packets — Verify replies come back.
If no replies arrive, check firewall translation rules (SNAT) and upstream routing for the reverse path.
Repeat on each hop — Walk through each router/firewall in the end-to-end path using the same method. This narrows the problem to a specific device.

Repeat the same approach on each hop/router in between the end-to-end path, you can easily isolate to the "problem" hop/router and discover the root cause.

Client Flow¶

Client Flow shows how much data each client is using in the current 15-minute window, and on what: download, upload and the destinations reached, by hostname and IP. tcpdump shows individual packets; Client Flow answers the question before it: who is using the bandwidth, and where is it going. Use it to:

find which client is saturating the link, or which app or service is behind a usage spike
check what a specific device is talking to, before deciding whether a packet capture is needed
answer a data-usage question or dispute while the traffic is still happening

Client Flow must be enabled first (ip client-flow on a LAN interface, or client-flow in a hotspot instance), and clients must use the router as their DNS server for hostnames to appear. See Client Flow for the configuration. The CLI shows only the window that is still open; closed windows are uploaded to mFusion and kept on the Usage Dashboard.

CLI Usage¶

RansNet# show ip client-flow ?
  mac      Show one client by MAC, with destinations
  detail   Top destinations per user/device
  <iface>  Interface or hotspot instance
  <cr>

Command	Shows
`show ip client-flow`	Every client on every enabled interface, with download, upload and number of destinations
`show ip client-flow <iface>`	Clients on one interface or hotspot instance only
`show ip client-flow [<iface>] detail`	Same as above, plus each client's top destinations
`show ip client-flow mac <MAC>`	One client and its top 50 destinations (MAC as `AA-BB-CC-DD-EE-FF` or `aa:bb:cc:dd:ee:ff`)

The header lines show the upload status:

Field	Meaning
`upload:` / `queue:`	mFusion server and the number of closed windows waiting to upload (normally 0)
`last:`	Time and result of the last upload (`OK` = accepted by mFusion)
`range:`	Start and end of the current 15-minute window, and the current time

Example: Find the Top Users¶

Device names are anonymized in the examples below.

RansNet# show ip client-flow
upload: portal.ransnet.com  queue: 0 chunk(s)
last: 20261025 08:01:12 portal.ransnet.com: 12 file(s) 8806B: OK 12
range: 20261025 08:00:00 - 20261025 08:15:00 (now 08:08:37)

vlan1 (network mode)
Device                   MAC                IP                 Download      Upload  Dests
------------------------------------------------------------------------------------------
Laptop-01                44-FA-66-39-20-95  10.18.18.76          5.0 MB      1.2 MB     92
Phone-01                 56-61-7D-A9-C3-56  10.18.18.52          1.8 MB    304.5 KB     15
(no name)                D4-DD-0B-00-16-A0  10.18.18.93        409.8 KB    169.8 KB      7
Laptop-02                60-57-18-83-21-56  10.18.18.200         6.0 KB      5.3 KB      8
MacBook-01               EA-7C-AC-85-84-9A  10.18.18.24        857.7 KB    636.2 KB     47
Watch-01                 A2-EA-01-F6-19-4E  10.18.18.139        18.0 KB      8.9 KB      2
Server-01                2E-73-7C-02-87-3D  10.18.18.27        412.4 KB    326.5 KB     34
Desktop-01               44-85-00-64-3A-02  10.18.18.131         5.6 MB      3.9 MB     85
Phone-02                 CC-62-00-A8-D1-9D  10.18.18.210        19.0 KB     21.4 KB     17
Tablet-01                CA-AE-0A-6C-01-DD  10.18.18.92          0.4 KB      0.4 KB      1
Tablet-02                4E-70-FC-DD-68-AE  10.18.18.192        86.2 KB     73.7 KB      5

(current 15-minute window so far; closed windows are queued for upload, then on mFusion's Usage tab)

(no name) means the device sent no hostname with its DHCP request. A - in the MAC column means the client isn't in the router's ARP table, for example a static IP behind another router.

Example: Drill Into One Device¶

RansNet# show ip client-flow mac 56-61-7D-A9-C3-56
upload: portal.ransnet.com  queue: 0 chunk(s)
last: 20261025 08:01:12 portal.ransnet.com: 12 file(s) 8806B: OK 12
range: 20261025 08:00:00 - 20261025 08:15:00 (now 08:08:38)

vlan1 (network mode)
Device                   MAC                IP                 Download      Upload  Dests
------------------------------------------------------------------------------------------
Phone-01                 56-61-7D-A9-C3-56  10.18.18.52          1.8 MB    304.5 KB     15
    Destination                          IP              Proto        Download      Upload Conns
    mmg.whatsapp.net                     57.144.101.32   tcp/443        1.5 MB     22.2 KB     1
    api.whatsapp.net                     57.144.187.32   tcp/443      148.1 KB    144.8 KB     9
    play.googleapis.com                  172.217.112.4   udp/443       22.8 KB     44.8 KB     4
    api.whatsapp.net                     57.144.187.32   udp/443       14.7 KB     21.7 KB     3
    androidwearcloudsync-pa.googleapis.. 172.217.117.4   udp/443       16.3 KB     19.6 KB     2
    g.whatsapp.net                       57.144.187.33   tcp/443       17.3 KB     17.8 KB     2
    g.whatsapp.net                       57.144.187.33   tcp/5222      12.3 KB     21.1 KB     1
    api.weather.com                      151.101.129.91  tcp/443       15.1 KB      2.5 KB     1
    spot-pa.googleapis.com               172.217.118.4   udp/443        6.2 KB      5.4 KB     1
    graph.facebook.com                   57.144.100.141  tcp/443        4.9 KB      2.3 KB     1
    -                                    10.18.18.1      udp/53         2.1 KB      1.0 KB    15
    -                                    57.144.160.3    tcp/443        1.1 KB      1.0 KB     1
    mtalk.google.com                     74.125.24.188   tcp/5228       0.4 KB      0.1 KB     1
    api.tselpvdo.id                      104.26.9.57     tcp/443        0.1 KB      0.2 KB     1
    media-sin6-3.cdn.whatsapp.net        157.240.15.60   tcp/443        0.0 KB      0.1 KB     1

(current 15-minute window so far; closed windows are queued for upload, then on mFusion's Usage tab)

How to read it:

The 1.5 MB to mmg.whatsapp.net is a WhatsApp media download (photos, videos, voice notes).
- 10.18.18.1 udp/53 is the phone's DNS traffic to the router: 15 lookups, all visible to Client Flow. A row such as dns.google 8.8.8.8 udp/443 instead means the device uses encrypted DNS and its other destinations will mostly show only an IP.
- in the Destination column means no DNS lookup was seen for that IP. A few such rows are normal (apps that connect to IPs they already know); many of them point to a DNS setup problem.
Names too long for the column end in ...

Example: Hotspot Mode¶

In hotspot mode the first column shows the login username (anonymized here):

RansNet# show ip client-flow
upload: portal.ransnet.com  queue: 0 chunk(s)
last: 20261025 16:15:53 portal.ransnet.com: 1 file(s) 1735B: OK 1
range: 20261025 16:15:00 - 20261025 16:30:00 (now 16:17:57)

vlan20 (hotspot mode)
Username                 MAC                IP                 Download      Upload  Dests
------------------------------------------------------------------------------------------
crew-01                  F6-3A-90-74-62-E3  192.168.81.11        3.2 KB      3.3 KB     22

(current 15-minute window so far; closed windows are queued for upload, then on mFusion's Usage tab)

When a user disputes their usage, run show ip client-flow mac <MAC> for that user to see which destinations account for the volume in the current window. For earlier windows, search the username on the mFusion Usage Dashboard.

Quick Checks¶

Symptom	Check	Fix
Most destinations show `-` (no hostname)	`show ip client-flow mac <MAC>`: is there a `dns.google` / `cloudflare-dns.com` row on port 443 or 853, or DNS to a public IP on port 53?	Make the router the clients' only DNS server. See Client Flow: Requirements.
`queue:` grows, `last:` shows an error	`ping` the mFusion server from the router	Fix WAN or routing to mFusion; check the router is an enabled host on mFusion. Queued windows upload automatically afterwards.
An interface or hotspot is missing from the output	`show running-config`	Enable `ip client-flow` (interface) or `client-flow` (hotspot instance).
A hotspot user is missing	`show security hotspot clients <instance>`	Only logged-in users are tracked.

Client Flow vs tcpdump¶

Aspect	Client Flow	tcpdump
Question answered	Who used the bandwidth, and on what?	What exactly is happening to these packets?
View	Per-client, per-destination byte totals over a 15-minute window	Individual packets, in real time
Overhead	Low enough to leave on permanently	Run only while troubleshooting
History	Up to 45 days on the mFusion Usage Dashboard	None, unless saved to a file
Typical next step	Found the client or destination? Use tcpdump with a `host` filter for packet-level detail	—

Client Flow output reveals which apps and services a person uses. Share it only with authorized staff and anonymize device names, usernames and MACs before putting it in tickets or documentation.

Remote SSH and Remote Web¶

Remote SSH and Remote Web let an engineer open a managed router's CLI or web GUI directly from mFusion with one click, even when the router sits behind NAT, carrier-grade NAT (cellular) or a customer firewall.

No firewall rules or port forwarding are needed on the router or on site. The router opens the connection itself, outbound to mFusion, so any router that can reach the mFusion server IP can be accessed remotely.

How It Works¶

The engineer clicks Remote SSH or Remote Web in mFusion.
mFusion sends the request to the router over its existing management channel.
The router opens an outbound, encrypted tunnel to mFusion. The connection always starts from the router; nothing connects into the router from the Internet.
mFusion opens the router CLI in a browser terminal (Remote SSH) or the router web GUI in a new browser tab (Remote Web).

Each session is secured dynamically:

One-time keys — the router generates a new key pair for every session and sends mFusion only the public key. Both sides destroy the key when the session ends.
Pinned server identity — the router accepts only the mFusion server identity sent with the request.
Idle timeout — a session ends after 15 minutes without activity, like an SSH idle logout: no typing in the Remote SSH terminal, or no page requests in the Remote Web tab. A session also ends after 4 hours at most, as a safety limit.
One session at a time — only one remote session per device is allowed. Opening a new one replaces the current one.
Restricted exposure — Remote SSH is never exposed to the Internet; the terminal runs inside mFusion. Remote Web is opened only to the engineer's own IP address.
Router login still required — the engineer logs in to the router as support, which is limited to the router CLI.

Supported Models¶

Series	Models	Remote SSH	Remote Web
Gateway series	CMG, HSG	Yes	Yes
Branch series	HSA, UA, XE, UAP	Yes	No — branch series has no web GUI; use Remote SSH

Requirements¶

The router is managed by mFusion and shows UP in the device list.
The router can reach the mFusion server IP. If a firewall sits in front of the router, it must permit these outbound connections from the router to the mFusion server IP:

Port	Purpose
TCP 443	Management channel (configuration and remote session requests)
TCP 10051	Monitoring
TCP 2299	Remote session tunnel

For Remote Web, the engineer's browser must be able to reach the mFusion server on TCP 50000–50999 (the port is shown in the address bar of the new tab).

Remote SSH¶

Step 1: Navigate to Device List, click the yellow Tools button for the router, and select Remote SSH.

Step 2: Wait for the session window to show Connected (typically 10–20 seconds), then click Open terminal.

Step 3: The router's login prompt opens in a new browser tab. Log in as support with the support password, then run enable for privileged commands.

The terminal is the same CLI as a local SSH session, so all commands on this page (ping, traceroute, tcpdump, show commands) work as usual.

Remote Web¶

Step 1: Navigate to Device List, click the yellow Tools button for the router, and select Remote Web.

Step 2: Wait for the session window to show Connected, then click Open router GUI. The router web GUI opens in a new tab.

Note

The browser warns about the router's self-signed certificate. This is expected; accept the warning to continue to the router GUI.

On a branch series router, Remote Web is not available because the router has no web GUI. mFusion shows a message to use Remote SSH instead.

Ending a Session¶

Click × in the session window to end the session immediately. Otherwise, the session ends by itself after 15 minutes without activity (closing the terminal or GUI tab counts as no activity), or after 4 hours at most. Either way, the tunnel is closed and the session keys are destroyed on both the router and mFusion.

Troubleshooting¶

Symptom	Likely Cause	Solution
Session window never shows Connected; the router does not respond	Router is offline, or cannot reach mFusion on TCP 443	Confirm the router shows UP in the device list. On the router, run `ping <mfusion-server-IP>` and check the upstream firewall permits outbound TCP 443.
Router responds, but the session fails to connect	Upstream firewall blocks outbound TCP 2299 to mFusion	Permit outbound TCP 2299 from the router to the mFusion server IP. On the router, `tcpdump interface eth0 port 2299` shows whether connection attempts leave the WAN.
mFusion reports that remote access is not available	mFusion remote-access service is not running	Restart the mFusion server service, or contact RansNet support.
Remote SSH terminal shows the login prompt but the password is rejected	Wrong support password for this router	Use the router's current `support` password.
Remote Web tab does not load	Engineer's network blocks outbound TCP 50000–50999, or the engineer's public IP changed after the session started	Permit the port range on the engineer's network, or close the session and start a new one from the current network.
Remote Web reports that the router has no web GUI	Remote Web requested on a branch series router	Use Remote SSH.

Security Best Practices¶

Grant remote access only to engineers who need it — use mFusion user roles to limit who can see Remote SSH and Remote Web.
Protect the support password — change it from the default and keep it different from the administrator password.
Close sessions when done — end the session instead of waiting for the 15-minute idle timeout.
Keep management closed on WAN — remote access does not need SSH or GUI open on the router's WAN; keep them restricted to LAN. See Device Hardening.