Mujin Remote Access and Support

Overview

Mujin Controllers are equipped with an integrated, secure remote access system designed to provide rapid support while maintaining the highest standards of cybersecurity.
 When permitted by network policies, each controller establishes a secure, outbound connection to the Mujin Support Gateway — a controlled environment that enables authorized support engineers to assist with troubleshooting, diagnostics, and maintenance activities.

Mujin’s remote access architecture:

• Outbound-only: Connections are initiated by the controller, preventing unauthorized inbound access from the public internet.
• Secure Gateway: All support activities are routed through Mujin’s managed Secure Gateway infrastructure, ensuring controlled and auditable access.
• Authentication and Encryption: Access is granted only after multi-factor authentication and is protected using strong encryption standards, safeguarding customer data and system integrity.

Remote support is critical to maintaining system performance, minimizing downtime, and meeting Service Level Agreement (SLA) commitments.
 By allowing secure remote diagnostics and system monitoring, customers benefit from faster response times, proactive issue resolution, and reduced disruption to operations — all without compromising their internal network security.

Network Prerequisites for Remote Support

To enable secure remote access to the Mujin Controller, certain network configurations must be in place.
 The controller initiates an encrypted outbound connection to the Mujin Support Gateway. To allow this connection, the following requirements must be met:

• Outbound Firewall Access:
  The customer’s firewall must permit outbound TCP connections from the Mujin Controller to the designated Mujin Support Gateway IP addresses over port 222.
• DNS Resolution:
   If the controller is configured to resolve domain names, outbound access to DNS servers (UDP/TCP port 53) must be allowed. Alternatively, static IP-based firewall rules can be used if DNS-based policies are not supported.
• NAT and Stateful Inspection:
   If Network Address Translation (NAT) is in use, the firewall must allow the Mujin Controller to initiate connections and enable return traffic on those connections. This is typically handled automatically by a stateful firewall.
• No Port Forwarding Required:
   Port forwarding from the public internet to the internal network is not necessary or recommended. All communication is outbound from the controller.
• Bandwidth and Latency Requirements:
  • A minimum available bandwidth of 100 Mbps is recommended between the controller and the Mujin Support Gateway.
  • Round-trip network latency (ping) should be 50 milliseconds or less to ensure optimal remote session performance.

Ensuring these prerequisites are satisfied is essential for enabling proactive support, remote diagnostics, and fast issue resolution.

SupportRequired ports needed to enable the remote support functionality:

If Network Address Translation (NAT) is used in the customer's network, the firewall must allow the Mujin Controller to initiate outbound connections and permit return traffic on those connections.
This behavior is typically managed by a stateful firewall.
 Port forwarding from the Internet to the Mujin Controller is not required or recommended.

IP Addresses Used for Remote Support

If the firewall does not support DNS-based policy management, static IP address rules must be configured according to the table below.

Mujin Support Gateway IP addresses may change periodically due to infrastructure updates.
 Mujin actively monitors these changes and will provide advance notice whenever possible to minimize disruption.

Detailed Packet Flow

The Mujin Controller establishes a secure outbound connection to the Mujin Support Gateway through the customer’s firewall or gateway device.
 The packet flow is as follows:

1. The Mujin Controller initiates an outbound TCP connection to the designated Mujin Support Gateway IP address on port 222.
2. The firewall or gateway device allows this outbound connection and automatically permits return traffic, assuming stateful inspection is enabled.
3. The Mujin Support Gateway authenticates the controller’s session and establishes a secure, encrypted communication tunnel.
4. Authorized Mujin support engineers access the controller only through this tunnel, using short-lived authentication certificates.

No inbound connection from the public Internet to the Mujin Controller is ever required or permitted.

Illustrated below is an example of the detailed packet flow from the Mujin Controller to the Mujin Support Gateway via the user's gateway (firewall).

Requirements on Quality of Service for the Network

To ensure high-quality remote support sessions and maintain optimal system performance, the following network service levels are required:

• Latency:
  The round-trip ping time between the Mujin Controller and the Mujin Support Gateway must be 50 milliseconds or less.
• Bandwidth:
  The available bandwidth between the Mujin Controller and the Support Gateway must be at least 100 Mbps.
• Session Establishment:
   For networks where outbound connections are opened manually (e.g., customer-triggered VPN access), the following additional requirements apply:
  • Support engineer VPN credentials should have a validity of at least one year.
  • The renewal process for credentials must be simple and take less than 5 minutes.
  • The login and authentication process must be completed within 1 minute.
  • Once established, the remote session must be allowed to remain active for at least 24 hours.

Meeting these network requirements is critical for maintaining responsiveness, stability, and continuity during remote support operations.

Examples of Configuring Access to Allow Remote Support

Below are examples of how to configure firewalls to permit the Mujin Controller's secure outbound connection to the Mujin Support Gateway.

Linux Firewall — iptables Example

# Allow DNS resolution (if no internal DNS server is available)
iptables -A FORWARD -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -p tcp --dport 53 -j ACCEPT

# Allow access to NTP (Network Time Protocol) servers
iptables -A FORWARD -p udp --dport 123 -j ACCEPT

# Allow outbound connection to Mujin Support Gateway
# (Note: IP addresses may change in the future)

# Global / Tokyo
iptables -A FORWARD -p tcp --dport 222 -d 150.249.222.225 -j ACCEPT

# Europe
iptables -A FORWARD -p tcp --dport 222 -d 18.158.251.246 -j ACCEPT

# United States
iptables -A FORWARD -p tcp --dport 222 -d 54.147.76.221 -j ACCEPT
iptables -A FORWARD -p tcp --dport 222 -d 137.184.16.117 -j ACCEPT

# Allow return traffic for stateful connections
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow outbound connection to Mujin Support Gateway
# (Note: IP addresses may change in the future)

# Global / Tokyo
iptables -A FORWARD -p tcp --dport 222 -d 150.249.222.225 -j ACCEPT

# Europe
iptables -A FORWARD -p tcp --dport 222 -d 18.158.251.246 -j ACCEPT

# United States
iptables -A FORWARD -p tcp --dport 222 -d 54.147.76.221 -j ACCEPT
iptables -A FORWARD -p tcp --dport 222 -d 137.184.16.117 -j ACCEPT

# Allow return traffic for stateful connections
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Frequently Asked Questions

How does Mujin secure the connection to the Mujin Controller?

Mujin ensures remote access security through multiple mechanisms:

• Support engineers authenticate through Mujin’s internal Identity and Authentication Management (IAM) system.
• After authentication, a short-lived session certificate is issued to the engineer.
• Connections are established through outbound-initiated SSH tunnels, routed via the Mujin Secure Gateway.
• Inbound internet access to the Mujin Controller is not required or allowed.
• All communications over the remote session are encrypted using modern cryptographic standards to ensure data security and integrity.

Who initiates the remote support connection?

The Mujin Controller initiates the connection outbound to the Mujin Secure Gateway.
Mujin support engineers do not initiate inbound connections directly to the controller.
 This outbound-only connection design:

• Enhanced security by eliminating the need for open inbound ports.
• Simplifies firewall and network configuration for customer IT teams.
• Reduces the system’s exposure to external network threats.

What methods are used to connect remotely?

Remote support sessions are established using SSH tunnels through the Mujin Secure Gateway.
 Key details of the connection method:

• The Mujin Controller creates a secure outbound SSH session to the Secure Gateway.
• Mujin engineers access the controller only after successful authentication and authorization through Mujin’s internal IAM system.
• No direct public internet SSH access to the controller is allowed.
• This architecture ensures secure, controlled, and auditable remote access.

What TLS version does Mujin use?

Mujin’s remote support feature does not rely on traditional TLS (Transport Layer Security) to initiate the connection.
 Instead:

• The secure session is based on SSH protocol version 2.
• All data exchanged during the remote session is encrypted through SSH using strong cryptographic algorithms.
• TLS is not required because the SSH tunnel inherently provides confidentiality, integrity, and authenticity.

What algorithm and ciphers protect the remote connection?

Mujin’s remote support system uses modern, secure cryptographic standards:

• Key Exchange Algorithm: curve25519-sha256
• Encryption Cipher: chacha20-poly1305

These algorithms are selected for their:

• High performance and low computational overhead.
• Strong resistance to cryptographic attacks.
• Proven reliability in securing SSH communications.