Frequently asked questions

noobtunnel combines a private WireGuard mesh, public HTTP/S, TCP and UDP publishing, and domain management in one dashboard, with a network of POPs you can choose for publishing. Bring-your-own-domain DNS includes record management and Pro/Admin GeoDNS and load balancing.

There is overlap: Tailscale connects devices through a private mesh and also offers Serve and Funnel for sharing services. Pangolin provides identity-aware access to public and private resources through connectors and clients. noobtunnel is an independently developed project inspired by both, with its own routing and hosted-service allowances. It is not affiliated with either, and compatibility or matching features should not be assumed.

Compare the workflows you need using the Tailscale feature overview, Tailscale Funnel documentation and Pangolin resource documentation.

We select POP hosting providers that advertise DDoS protection. That protection is supplied by the hosting provider, and its coverage, capacity and response depend on that provider's service. We do not independently guarantee their advertised protection or promise that every attack will be stopped.

Provider protection does not replace application security. An HTTP request flood, an expensive endpoint or an attack on your backend can still affect availability. noobtunnel also offers resource access controls and HTTP/S security settings, including bot checks and abuse-reputation blocking. These controls have different purposes from network-level DDoS mitigation.

Multiple POPs and health-based DNS routing help when a location becomes unavailable; they do not scrub attack traffic or make a service immune to DDoS attacks.

The hosted control service and its DNS run across multiple POPs with replicated configuration. The shared hostname, tunnel.byenoob.com, uses Auto GeoDNS and HTTPS health checks. When a POP fails those checks, DNS selects the geographically nearest remaining healthy POP. If every checked POP is unavailable, DNS cannot provide a healthy route.

Agents using that hostname retry after losing their control connection and can reconnect through another healthy POP, updating their mesh hub. Direct device-to-device mesh traffic can continue without the failed relay; traffic using that POP as a relay may be interrupted while agents reconnect.

Failover takes time: health checks, DNS caches and connection retries affect recovery. Existing connections are not transferred between POPs. This redundancy reduces dependence on one location, but we do not currently publish a measured uptime percentage or offer an uptime SLA.

A published resource currently listens through its selected exit POP. Redundancy of the dashboard and shared agent hostname does not automatically move that resource's public listener, address or port if its exit POP fails. Your backend also needs to remain reachable.

Publishing a service across multiple POPs is planned for Pro and is shown as coming soon on Pricing. It is not currently an available automatic publishing-failover guarantee. Backend load balancing within one published resource is a separate feature.

Normally, no. The agent establishes an outbound connection, and a published resource accepts visitors at the POP before forwarding traffic to your agent and backend. This can work behind CGNAT. Your network still needs to allow the required outbound connections, and the configured backend must be reachable from the agent.

Direct mesh connections depend on NAT and firewall conditions. When a direct path cannot be established, traffic can use a POP relay.

Visitors to a publicly published service do not need a noobtunnel agent. They use the service's public hostname or assigned port. Devices accessing your private mesh need an enrolled agent or a configured route into that mesh. Publishing a service makes it publicly reachable unless you apply access controls.

Yes. You can point DNS at a published service, or bring a registered root domain to BYOD and manage common DNS records through noobtunnel's nameservers. Copy your existing records, including mail records, before changing nameservers. DNSSEC signing for hosted BYOD zones is not currently available.

Pro/Admin accounts can configure country rules or Auto GeoDNS with load balancing. Auto uses our iplog service to determine a country and selects the geographically nearest healthy configured address. When the resolver supplies a visitor subnet, DNS uses it; otherwise it uses the resolver's location. Unknown locations use the default balanced pool. Auto does not measure the fastest connection or create a public listener on another POP.

WireGuard protects mesh traffic between its tunnel endpoints. Public service publishing has a different trust boundary: HTTPS can terminate at the POP proxy, which handles the request before forwarding it to your backend. Backend encryption and authentication are separate settings. Do not assume a published service has one uninterrupted end-to-end HTTPS session.

The hosted service processes account information, connection metadata and operational logs. It is not a no-logs anonymity service. See Privacy & cookies for details.

Your internet connection, backend performance, route, protocol and available shared POP capacity all affect speed. Direct mesh traffic takes a different path from relayed mesh traffic and published resources. Plan allowances apply to the relevant traffic path; an advertised maximum is not a dedicated or guaranteed connection speed. See Pricing for current allowances.

Pro subscriptions are not currently available to purchase. Features marked coming soon describe planned availability, not current entitlements. You can start with the hosted Free service where registration is enabled.

Contact admin@byenoob.com with the affected domain or resource, approximate time in UTC and the error you saw. For security or abuse reports, include enough detail to investigate safely. Do not send passwords, private keys or enrollment/API tokens. See Contact and the troubleshooting guide.