Frequently Asked Questions

Pick the endpoint with the lowest latency from your location. We have a latency test page that measures the round-trip time from your browser to each endpoint — run it and choose the one with the smallest number. The test includes some overhead from TLS and HTTP, so your actual tunnel latency will be lower than shown.

In general: if you're on the East Coast or in the Midwest, turnpike (New Jersey) will be fastest. If you're on the West Coast, caltrain (Silicon Valley) will be faster. The difference matters most if you're serving real-time traffic like game servers or video calls.

No — and this is by design. We route your static IP directly to your device. We are not a middlebox and we do not filter or inspect your traffic. The entire point is that you get a real public IP with full control over what runs on it.

This means you are responsible for your own firewall. Any port that isn't protected by software on your device (or your router) is reachable from the internet. If you're running services you don't want exposed, make sure they're protected before connecting.

Most operating systems include a built-in firewall:

• Ubuntu / Debian — ufw
• Fedora / RHEL — firewalld
• Windows Defender Firewall
• macOS Firewall
• Router-level: pfSense, OPNsense, and GL.iNet all have built-in firewall/NAT rules

The exception is outbound port 25, which we block by default on our end to prevent abuse by spammers — see the question above.

Yes — this is called policy-based routing. Your inbound traffic arrives via the tunnel on your static IP, and your normal outbound traffic (browsing, downloads, etc.) continues to go out through your regular ISP connection. Only the return traffic for inbound connections goes back through the tunnel.

The default WireGuard config routes all traffic through the tunnel (AllowedIPs = 0.0.0.0/0). Policy-based routing is not a WireGuard config option — it requires routing rules on your router or Linux box. The basic idea: packets arriving from the tunnel get marked, and a separate routing table sends replies back the same way, while unmarked outbound traffic uses your normal default route.

The important thing to understand is that your OS won't automatically know to send replies back via the tunnel just because the inbound packet arrived that way. Without explicit policy routing rules, replies leak out your ISP connection with the wrong source IP and the connection breaks. You have to explicitly tell your router to send return traffic back via the tunnel.

See the Policy-Based Routing guide for step-by-step instructions on Linux (fwmark + ip rule), BSD/pfSense/OPNsense (pf reply-to), and other routers. There's also an advanced section covering multiple IPs routed to different LAN hosts.

Same endpoint location: Yes. If both tunnels are on the same endpoint (e.g. both on turnpike), we can move IPs between them, merge two tunnels into one, or split a tunnel's IPs across new tunnels. Use the contact form to request this and we'll handle it for you.

Different endpoint locations: No. IPs are tied to the subnet of their endpoint location and can't be moved between locations. If you need an IP at a different endpoint, you'll need to create a new tunnel there.

Use the contact form and select "Feature Request" as the category. Describe what you're trying to do and why it would be useful. We read every submission and use them to prioritize the roadmap.

Some things we've heard interest in: expanded endpoint locations (West Coast, Europe, Asia), a reverse proxy option (like rathole or frp) instead of WireGuard, IPv6 support, managed firewall rules, or API access for programmatic IP management. Even if it's on this list, let us know — the more people ask for something, the sooner it gets built.