
Mutiny offers an optional Remote Support and Managed Service capability that allows authorised Mutiny engineers to securely access your Mutiny appliance for troubleshooting, software updates, configuration assistance and proactive maintenance.
Remote connectivity is provided using Tailscale, a secure mesh VPN built on the WireGuard® protocol. Tailscale creates an encrypted private connection between the Mutiny appliance and authorised systems within Mutiny's support network without requiring the appliance to be exposed directly to the Internet.
How It Works
Remote support is controlled from the Mutiny Maintenance Interface.
When remote access is required:
Contact Mutiny Support and request a Support VPN authentication key.
Open the Maintenance Interface on the Mutiny appliance.
Select the System Operations tab.
Enter the authentication key supplied by Mutiny Support into the Auth Key field.
Click Start Support VPN.
The appliance will establish an outbound connection to the Tailscale network.
When successfully authenticated, the Maintenance Interface will display a green Support VPN Connected confirmation.
No inbound port-forwarding or public IP address is normally required.
Once connected, authorised Mutiny engineers can access the appliance using its private Tailscale address for services such as:
HTTPS – appliance administration and diagnostics.
SSH – command-line support and maintenance.
Access remains protected by Tailscale's encrypted private network and Mutiny's Tailscale access-control policies.
Network and Firewall Requirements
The Mutiny appliance requires outbound Internet access to establish and maintain the Support VPN.
Tailscale uses several connection methods. Wherever possible it establishes a direct peer-to-peer WireGuard connection between the Mutiny appliance and Mutiny Support. If a direct connection cannot be established because of NAT or firewall restrictions, Tailscale can use an encrypted DERP relay.
For best reliability and performance, the customer's firewall should permit the following outbound traffic from the Mutiny appliance:
| Protocol | Port | Destination | Purpose | Requirement |
|---|---|---|---|---|
| TCP | 443 | Internet / Tailscale services | Tailscale control plane, authentication and DERP relay traffic | Required |
| UDP | 41641 | Internet | Direct WireGuard peer-to-peer connections | Strongly recommended |
| UDP | 3478 | Internet | STUN/NAT discovery and traversal | Strongly recommended |
| TCP | 80 | Internet / Tailscale services | Optimised control-plane transport and captive-portal detection | Optional/recommended |
TCP 443
Outbound TCP 443 is the most important requirement.
It is used for communication with the Tailscale coordination infrastructure and for encrypted DERP relay connections when a direct WireGuard connection cannot be established.
For this reason, allowing the appliance to connect to arbitrary Internet destinations on TCP 443 provides the most reliable configuration.
UDP 41641
Tailscale normally uses UDP source port 41641 for direct WireGuard peer-to-peer communication.
The firewall should therefore permit the Mutiny appliance to initiate:
UDP from source port 41641 to Internet destinations on any UDP destination port.
This is preferable to defining UDP 41641 simply as a destination port. The remote peer's port cannot necessarily be predicted because of NAT and other network conditions.
Allowing this traffic significantly improves the likelihood of establishing a direct connection between Mutiny Support and the appliance.
If UDP connectivity is restricted, Tailscale will normally attempt to use a DERP relay instead.
UDP 3478 – STUN
Outbound UDP 3478 is used by Tailscale's STUN services to determine the appliance's public IP address and NAT characteristics.
The firewall should permit:
UDP from the Mutiny appliance to Internet destinations on destination port 3478.
This assists Tailscale in determining the most efficient method of establishing a peer-to-peer connection.
TCP 80
Tailscale can also use outbound TCP 80 for an efficient encrypted connection to its coordination infrastructure and for captive-portal detection.
This is not essential because Tailscale can fall back to TCP 443, but permitting outbound TCP 80 can improve connection establishment and avoid unnecessary timeouts.
Firewall Allow-Listing
Some organisations restrict Internet access using destination FQDN or IP allow-lists.
Where this is the case, the following Tailscale services should be permitted:
controlplane.tailscale.comlogin.tailscale.comlog.tailscale.comconsole.tailscale.com
Tailscale also operates a worldwide network of DERP relay servers. These use hostnames in the form:
derpN-all.tailscale.com
where N identifies a DERP region.
The number and addresses of DERP servers can change as Tailscale expands its infrastructure. For this reason, Tailscale recommends allowing outbound TCP 443 to the Internet rather than attempting to maintain a fixed list of DERP server IP addresses.
Where an organisation must use destination-based filtering, its firewall administrators should ensure that Tailscale control-plane and DERP destinations are not blocked.
IP-Based Allow-Listing
Where firewall policy requires IP addresses rather than DNS/FQDN rules, Tailscale currently publishes static address ranges for some of its core services.
For login.tailscale.com and controlplane.tailscale.com:
IPv4:
192.200.0.0/24IPv6:
2606:B740:49::/48
For log.tailscale.com:
IPv4:
199.165.136.0/24IPv6:
2606:B740:1::/48
These ranges do not represent the complete set of DERP relay destinations. Where possible, FQDN-based rules or unrestricted outbound TCP 443 should therefore be used instead of relying exclusively on these IP ranges.
Internet Access Summary
For a standard deployment, the recommended firewall policy for the Mutiny appliance is:
| Direction | Protocol | Port | Action |
|---|---|---|---|
| Outbound | TCP | 443 | Allow |
| Outbound | UDP | 41641 source | Allow to Internet |
| Outbound | UDP | 3478 destination | Allow to Internet |
| Outbound | TCP | 80 | Allow where permitted |
| Inbound from Internet | Any | Any | Not required |
No inbound Internet firewall ports need to be opened or forwarded to the Mutiny appliance.
The Mutiny appliance does not need a public IP address.
Direct and Relayed Connections
Tailscale will normally attempt connection methods in the following order:
Direct peer-to-peer connection – encrypted WireGuard traffic passes directly between the Mutiny appliance and Mutiny Support.
Peer relay – where configured within the Tailscale network.
DERP relay – encrypted traffic is relayed through Tailscale infrastructure when a direct connection cannot be established.
The encryption remains end-to-end when DERP is used. The DERP server relays the encrypted packets but cannot decrypt the support session.
A direct connection is preferable because it normally provides lower latency and better performance, but a DERP connection is fully suitable for remote support.
Important: "Support VPN Connected"
A green Support VPN Connected message confirms that:
Tailscale is running on the Mutiny appliance.
The appliance has successfully authenticated.
The appliance can communicate with the Tailscale control infrastructure.
The appliance has joined the Mutiny support tailnet.
However, this does not necessarily confirm that a usable peer-to-peer or DERP data path has been established between the appliance and Mutiny Support.
For example, a restrictive gateway firewall may permit HTTPS communication with the Tailscale control plane while blocking UDP peer-to-peer traffic and/or access to DERP relay servers.
It is therefore possible for the appliance to report Support VPN Connected while Mutiny Support is unable to establish an SSH or HTTPS connection to it.
If this occurs, the customer's network administrator should check that the firewall permits the traffic described in the Network and Firewall Requirements section above.
Firewalls, NAT and Security Inspection
Most conventional stateful firewalls and NAT gateways work with Tailscale without requiring special configuration.
More restrictive enterprise firewalls can, however, prevent direct connections or interfere with Tailscale traffic. Examples include:
Blocking outbound UDP.
Symmetric or "hard" NAT.
Restricting TCP 443 to an approved destination list.
Blocking Tailscale DERP relay destinations.
Application-aware firewall policies that identify and block VPN traffic.
SSL/TLS inspection of Tailscale control-plane connections.
Very short UDP session timeouts.
Firewall policies that prevent peer-to-peer traffic.
If the Support VPN authenticates successfully but Mutiny Support cannot reach the appliance, these policies should be investigated.
Where SSL inspection is used, Tailscale control-plane traffic should normally be excluded from HTTPS interception/decryption.
Security
The Remote Support VPN has been designed so that the Mutiny appliance does not need to be exposed directly to the public Internet.
End-to-End Encryption
All support traffic across the Tailscale network is protected using WireGuard encryption.
No Internet-Facing Management Ports
SSH and HTTPS do not need to be opened or port-forwarded through the customer's Internet firewall.
These services are accessed through the appliance's private Tailscale address.
Identity-Based Access
Access to the Mutiny support tailnet is controlled by authenticated identities and Tailscale access-control policies. Only authorised Mutiny Support systems and personnel are permitted to access customer appliances.
Customer-Controlled Access
The customer controls when the Support VPN is activated.
When remote support is no longer required, select:
Disconnect Support VPN
from the Maintenance Interface.
This terminates the appliance's connection to the Mutiny support tailnet.
Troubleshooting
Tailscale Diagnostic Log
The Mutiny appliance includes a dedicated Tailscale Log within the Diagnostics Interface. This should be checked whenever the Support VPN fails to connect or reports as connected but Mutiny Support is unable to reach the appliance.
To view the log:
Open the Mutiny Main Interface.
Select the Diagnostics menu url.
Select Tailscale Log.
The log provides diagnostic information from the Tailscale service and can help identify:
Authentication and connection failures.
Tailscale service start-up problems.
Control-plane connectivity.
NAT traversal and peer connectivity.
DERP relay connectivity.
Network and firewall-related errors.
Changes in the Tailscale connection state.
Mutiny Support may ask the customer to provide the contents of this log when investigating a remote-access problem.
The diagnostic log can also be accessed directly from the Maintenance Interface at:
/interface/displayDiagnostic.refresh.do?action=tailscale_log
For example:
https://<mutiny-appliance>/interface/displayDiagnostic.refresh.do?action=tailscale_log
If "Support VPN Connected" Is Not Displayed
Open Diagnostics → Tailscale Log and check for connection or authentication errors.
Confirm that the Mutiny appliance has Internet access.
Confirm that outbound TCP 443 is permitted.
Check that DNS resolution is functioning.
Check that the required Tailscale domains are not blocked.
Check whether SSL/TLS inspection or application filtering is interfering with Tailscale.
Attempt to start the Support VPN again.
If "Support VPN Connected" Is Displayed but Mutiny Support Cannot Connect
A Support VPN Connected message confirms that the appliance has authenticated and is connected to the Tailscale control infrastructure. It does not necessarily confirm that a usable data path exists between Mutiny Support and the appliance.
In this situation:
Open Diagnostics → Tailscale Log and look for peer connectivity, DERP, STUN or network-related errors.
Confirm outbound UDP traffic is permitted, particularly traffic originating from UDP source port 41641.
Confirm outbound UDP destination port 3478 is permitted for STUN/NAT discovery.
Confirm outbound TCP 443 is permitted to Tailscale's DERP relay infrastructure and is not restricted solely to the Tailscale control-plane addresses.
Check for firewall application-control policies that block Tailscale, WireGuard, VPN or peer-to-peer traffic.
Check whether SSL/TLS inspection is being applied to Tailscale connections.
Check whether the gateway firewall is using restrictive or symmetric NAT that may prevent direct peer-to-peer connectivity.
Where possible, temporarily test the appliance through a less restrictive Internet connection. If Mutiny Support can then connect, this strongly indicates that the site's gateway firewall or Internet security policy is preventing the connection.
If the appliance is shown as online/connected in Tailscale but Mutiny Support cannot establish either an SSH or HTTPS connection, the Tailscale Log should be supplied to Mutiny Support together with details of any firewall restrictions applied to the appliance.
Mutiny Support can work with the customer's network or security team to identify the required firewall changes.
Further Assistance
If your organisation operates a restricted Internet gateway, proxy, next-generation firewall or destination allow-list, please provide this document to your network/security administrator.
If further assistance is required, contact Mutiny Support. We can work with your network team to verify the firewall requirements needed to establish secure remote support connectivity.