“Create P2P tunnels instantly that bypass any network, firewall, NAT restrictions and expose your local network to the internet securely, no Dynamic DNS required.”
Static IP address and Dynamic DNS can expose your network to attackers on the internet. With Holesail, you expose only the port you choose.
Er, wut? If you’re exposing a port, then your public IP is being used, as a port is a subset of an IP interface. So even Holesail uses the public IP in some way…thats how the internet works. Unless they’re only making outbound connections, which isn’t a new idea at all - Hamachi was doing it 20 years ago.
This sounds like FUD to me - of course your public IP is used, whether static or dynamic. How do they supposedly mitigate this risk?
There’s nothing on the home page saying how it works, or how it’s different than current solutions.
I’m intrigued to see a new tool in this space, but this one is starting off leaving a bad taste. Even Tailscale admits they use Wireguard, and even have a comparison between Wireguard and Tailscale that’s pretty honest (though they focus on what Tailscale adds).
Being open and transparent is a minimum today - anything less and it’s not worth the time for a second look.
Because you’re only ‘exposing’ the port on the peer to peer network.
You “publish” a port to holesail, then clients have to create a local proxy via holesail before they can access it.
I agree, It’s a dumb pointless claim. But I don’t think it’s misleading.
It looks like holesail is just tailscale, but on a much smaller scale. It’s not networks, it’s just ports.
My guess is that this works similar to a Tor hidden service, where you can’t even access the open port without a key of some kind and then you can only access that specific port. It’s not the same as having a port open on your IPv4 address since from the router’s perspective it’s only an outgoing connection. Somebody portscanning you wouldn’t find that port open. Though I could be wrong.
This VPN protocol usually uses a private key (client) / public key (server) combo that is used to connect through a public IP address (the 2 nodes can’t communicate it without) using the specified TCP or UDP (more often lately) and port to create the VPN tunnel that’s gets established during the handshakes.
There is a whole lot more going on with the process but that’s a high level view. But I have a WireGuard VPN service running on a raspberry pi that I put in a DMZ on my perimeter firewall.
But a port scanner would be able to see that port is open. Make sure you keep your software up to date. Hopefully the software devs of the VPN application is keeping their stuff up to date to avoid any vulnerabilities getting exposed in the code and a backdoor getting created because of it. As long as that doesn’t become an issue, no one will be able to get through without the private key. And those are usually uncrackable in a lifetime with the complexity and length of the key.
Open UDP ports are pretty secure and rarely found by scanners. The basic issue with scanning for UDP is, that most services don’t respond to random garbage you try to probe then with. Without getting a response back, the scanner has no way of knowing if there is something running on that port or not.
Wireguard in particular only responds if the correct key is given.
Also make sure your firewall DROPs (usually the default, but do check) disallowed connections instead of REJECT. This way any UDP probing, whether it’s to an open port or closed one just times out with no way for the scanner to distinguish them.
