What is not working?
Choose the closest symptom. These checks help isolate a problem; use the supported release procedure before changing routes, DNS or firewall rules.
A device cannot join or stays offline
Check ordinary internet access, the intended workspace, supported client version and enrollment status. Note whether the failure occurs before approval, while starting the tunnel or after a connection has worked. If another VPN is running, report it rather than removing its routes blindly.
Review enrollment prerequisites →The private address works, but the private name does not
Check the exact private name, workspace and expected address. Compare name resolution with a direct-address connection from the same device. A DNS failure and an access denial are different problems; changing to a public resolver will not necessarily resolve a private workspace name.
Understand private identity and names →A private server, printer or LAN device cannot be reached
Confirm access membership, the target address and listening port, then the gateway’s current state. Check the approved subnet, overlapping local addresses and return route. Try the target by its known address: automatic local discovery may not cross a routed network. Keep the application’s login and drivers in place.
Inspect the gateway path →A public address times out
Confirm the allocation is active and the change has been applied. Check the service locally, the assigned address family, inbound rules and target port. For a gateway, include forwarding and the reply path. Test from an external connection; a LAN test may follow a different route.
Follow Public IP delivery →An allowlisted provider sees the wrong source address
Test the actual workload, destination and address family. With Public IPs, verify that the selected destination is routed through Fibmesh and uses the assigned source. With Outbound, confirm the active full-tunnel profile and stable allocation. Check tunnel failure or deliberate bypass without assuming an address shown in the dashboard is the source of every request.
Check the routing choice →A setting is saved, but the connection has not changed
Compare desired state with the latest reported result and its timestamp. A pending, partial, rejected or failed application needs investigation on the affected endpoint or gateway. Do not repeatedly create duplicate allocations to force an update.
Understand applied state →A Publish application is unreachable
Publish is available with assisted setup. Verify that the selected connector can reach the application address and port. Loopback means the connector’s own host; a different LAN server needs its reachable address. Keep web-app authentication separate from publication.
Read Publish limits and compatibility →Prepare a useful support report
Copy this outline into your agreed support channel. Describe one failing connection and include only the relevant, redacted observations.
Product and intended connection:
Affected device or gateway identifier:
Operating system and client version:
Time of failure and timezone:
Expected result:
Actual error or result:
Last time it worked / recent changes:
Policy or allocation state and last update:
Checks already performed:Never include private keys, passwords, tokens, raw WireGuard profiles or unredacted support bundles. Review screenshots and logs before sharing them. Do not open unrelated ports or disable protections just to gather evidence.
Where to get help
Invited customers should use the support route supplied with their service or evaluation. This website has no connected ticket queue or published response-time commitment. Contact Fibmesh is the general enquiry route, not an incident acknowledgement or support SLA.
Service status explains the current monitoring state. A working website is not evidence that every service component is healthy.