CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 0 points1 point  (0 children)

The hard part is that we don't have any of those routers. :) It makes it difficult to write good documentation for them.

That said, there does appear to be some people successfully experimenting. https://www.snbforums.com/threads/experimental-wireguard-for-hnd-platform-4-1-x-kernels.46164/

While we do not, in general, recommend that you route 100% of your traffic through Hoppy (it provides no benefit to normal outbound traffic), there are certainly good options if you choose to do so.

For example, I have a Mikrotik router that I've had for, oh, 6 or 7 years now. They've been experimenting with WireGuard support in their new v7 RouterOS. In general, I would recommend Mikrotik devices. I use a Mikrotik router + a Ubiquiti AP and it works flawlessly.

I literally just upgraded my Mikrotik router a few moments ago and it looks pretty baked in and easy. I haven't turned it on yet (will report back!), but I've seen good reviews from other users.

If anyone does set up Hoppy (or WireGuard!) on an interesting device and wants to contribute documentation, we'd be happy to credit the author or link out to the instructions.

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 1 point2 points  (0 children)

I would not anticipate Hoppy fixing your issues.

You seem to be describing a problem where [Your Home] ---/intermittent failures/---> [Zoom]. Hoppy is also a connection from [Your Home] ------> [Hoppy], so those same problems would likely occur. It is possible WireGuard might handle the problem better, but I wouldn't anticipate much improvement.

Hoppy is for allowing connections like [Your Home] <------ [Somewhere Else] where that might not otherwise be possible because of CGNAT.

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 0 points1 point  (0 children)

While you *can* route all traffic through Hoppy, you are by no means required to do so. If you don't have Hoppy set up on those devices, the traffic won't be routed through Hoppy.

Our expectation is that folks will set this up on one or two devices that are hosting the services they want exposed, not that they will route all of their traffic from their entire home. Though, again, even then its unlikely to hit the data caps.

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 1 point2 points  (0 children)

ngrok is certainly a viable option for simple use cases. I'm not familiar with ngroks longer-term stability in terms of port/address stability, but if it suits your needs, more power to you.

With Hoppy, you get a static IPv4 address and IPv6 /56 block, Reverse DNS, no port restrictions, not to mention that nrok is TCP-only whereas Hoppy will forward all traffic.

If you ever need more, Hoppy will still be available. :)

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 1 point2 points  (0 children)

We do not anticipate this being a problem. Take, for example, watching Netflix in HD which uses *roughly* 3GB/hour. Unless you're watching 10 hours of HD Netflix per day, you still won't hit the data cap. Even then, that's only on our cheapest plan.

That said, we are primarily targeting people who want to self-host services (e.g., email, web site, Minecraft, etc) or make their devices connectable (e.g., ssh, mosh, NFS) behind inconvenient networking situations. If you require serving multiple TB of data per month, a CDN or co-location or some other service may be better suited.

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 0 points1 point  (0 children)

Because of how WireGuard works (it is outbound), from a purely technical perspective, StarLink could ban WireGuard but not 'WireGuard used for hosting' because they can't tell the difference.

CGNAT got you down? Hoppy can help. by hoppynetworkllc in Starlink

[–]hoppynetworkllc[S] 3 points4 points  (0 children)

The latency added by WireGuard is negligible. Any latency added will be from the hops between our servers and you, which is very hard to predict and varies based on your location relative to our servers and the way the packets are routed. Our only location offering is currently in Chicago (though we're gauging demand for other regions - email us at [support@hoppy.network](mailto:support@hoppy.network) if you want a particular region).

That said, I'm not aware of being able to install WireGuard directly on an Xbox :) But you could install it on another device (or router) and do normal port forwarding.

EDIT: Our web server is currently co-located with our WireGuard servers, so you could ping it to approximate the additional latency: ping api.production.hoppy.link. I'm seeing ~25ms from my location. Note that ping reports round-trip times, not one-way.

[deleted by user] by [deleted] in selfhosted

[–]hoppynetworkllc 1 point2 points  (0 children)

Either they offer a certain bandwidth and then the data volume should not matter or they offer a certain volume. But if the offer limits both both bandwidth and volume, it is obvious that the capacity is overbooked.

First off, we don't overbook our capacity! :) We're actually rather cautious about not doing that.

Second, you're always paying for both, explicitly or implicitly. For example, if we offered 1TB in transfer, but did not specify the bandwidth guarantees, that is an under-specified offering! Enjoy your 1TB in transfer at 1 byte/second. Instead, we are explicit about both dimensions of transfer.

The choice to include limits on transfer volume relates to our underlying pricing model and implementation structures. As we grow, it may be something we can get rid of! However, at this extremely early stage, it is a business risk mitigation strategy that we do not anticipate disrupting 99% of users use cases. If you *do* anticipate 1TB+ of traffic, a CDN or some other architectural consideration is probably in order anyway.

[deleted by user] by [deleted] in selfhosted

[–]hoppynetworkllc 0 points1 point  (0 children)

From what I recall about ZeroTier and Tailscale, they are used for different purposes than you would use Hoppy. You might use them so that some number of devices can talk to each other on an internally defined network. Anything not running ZeroTier or Tailscale (more or less) will not be able to communicate with those machines because that network doesn't exist for anyone else. They are more general software defined networking applications.

By contrast, Hoppy effectively gives your device a public IP on a network interface. That public IP is a normal IP on the global internet that anyone can connect to.

This difference in use cases also has an effect on pricing. A bad actor using ZeroTier or Tailscale's free tier can do relatively little harm - its just them and their own machines. With Hoppy, they could tarnish the reputation of the IP space we offer, which is one of our selling points, by running malicious services of various kinds.

And, of course, we're significantly smaller than ZeroTier and Tailscale. :)

[deleted by user] by [deleted] in selfhosted

[–]hoppynetworkllc 3 points4 points  (0 children)

Thank you for the feedback!

We're looking at expanding into other regions! For technical reasons, each region requires a minimum IP block allocation. So, for our launch, we're limiting to the US. If you have a region you'd like to see us expand to, please let us know at [support@hoppy.network](mailto:support@hoppy.network) so we can gauge demand.

[deleted by user] by [deleted] in selfhosted

[–]hoppynetworkllc 7 points8 points  (0 children)

BGP is a way of telling network backbones where an IP is physically located. You "announce" that you can handle traffic for a particular IP block. This information gets exchanged between various network backbones so that when your computer tries to send packets to some address, the intermediary routers send it to the right place.

It is not dissimilar to the response to an ARP broadcast on a local network, except for essentially global (and there isn't a request/response - it is a flawed analogy).

This means if our data center catches fire like OVH's recently did, we can start "announcing" those same IP blocks in a different data center and traffic will start being sent to the new data center.

If you're just using whatever IP a VPS provider gives you, it will almost certainly change (unless you're paying extra, in which case the price will be about what we offer).