Show HN: SmokeVPN – All-in-One WireGuard VPN Hub – Switch Exits in Realtime
smokevpn.comI have started developing a prototype of a WireGuard VPN hub, where I could set a custom exit to a specific device, for example, my TV box would use a VPN in Germany, while my desktop a VPN is Serbia and I could switch the exit in realtime without having to stop the VPN connections and consequently no disconnections (ssh, etc).
The project grew, and I ended up adding SOCKS5 and HTTP proxy, Tor exits, exit pools, random exits, timed exits, and exits/routes based on domains or IP addresses. I also added an in-house DNS with several default block lists (malware, gambling, social media, etc.)
I found this project to have potential and decided to commercialize it, Smoke VPN was born.
The logs live entirely on the RAM, and I plan to open-source the full stack as soon as I get feedback from real users, people like you...
Can you please try the project for free for 7 days or 50 GB (whichever comes first)?
You don't need an account, email or password and you can add up to 10 devices.
Real feedback is truly welcome!
Comments
This looks quite promising. I think I'll give it a shot. This actually has exactly what I look for in vpn providers. Specifically what I like are the following features:
- unusual countries,
Appreciate the option, its less likely in my experience to face Captcha's when you use exit nodes in Central or South America or the MENA region (though it would be nice to see more south American options). Moldova and Bulgaria is nice too for the opsec nerds. No idea how much that jurisdictional aspect actually affects things, not that I'm talking about crime: I think people just like to feel like you have privacy even if its a little bit of larp lol
- the socks5/http feature
this was what always had me returning to mullvad, great for specific things such as Freetube to dodge youtube vpn blocks, doing Jdownloader2 load balancing to avoid strict anti scraping or anti downloading website features, or AI agents or AI powered web search, etc.
The socks5/http endpoints are by far the best feature here IMO.
- routing rules / custom exit node pools
this reminds me of the SPN app's VPN settings but is different enough to be considered genuinely novel (at least as far as I've seen offered by a VPN provider) and its really interesting. Great idea, obviously gotta try it first before I speak on this but thanks for making this dude this is cool.
My constructive feedback based on what I've seen so far:
The biggest thing missing IMO? Socks5/HTTP endpoints tied to each exit node in the same way mullvad does.
Why?
Firefox container tabs
Idk how much other people even do this is by far my biggest use of VPNs on a day to day basis and a foundation for online privacy: hooking up custom firefox container tabs, using socks5 endpoints, to different VPN exit nodes. One or two container tabs per exit node for my favorites. So so powerful and useful for isolating streams / online identities / accounts. Its not just about disassociating your accounts from one another but about keeping your account IP at least geographically consistent so it doesn't trigger back end bot detectors. For example if I log in with a lot of varying VPN IPs github will flag my account and it becomes nearly impossible to utilize their API which is a pain in the ass. Among other things.
Its rare to find this feature! I understand this is possible through the setup offered currently, but only two socks5 endpoints is limiting and dealing with the credential aspect sometimes gets buggy because you can only pass it once when setting the container tab's proxy. If there were socks5/http offered hardcoded for each exit server, using internal IP so only logged in customers can utilize them, you'd make it much easier for a guy like me. But I understand this is probably not something that will be a top concern seeing that you are just getting this thing started.
That said, I have a sneaking suspicion that there are a LOT of mullvad VPN users who learned this powerful trick and stick with mullvad because I believe the only other provider with that feature is IVPN and they are fairly slow and limited in the server selection...meaning you might be able to appeal to a lot of folks potentially if you played your marketing / Word of mouth cards right.
Regardless, this feature (even if limited) and the exit node pools/custom rules will probably be why I'll be buying a subscription over anything else in the future! This is a super promising project. Where can I follow your development updates? I hope you see success with this, its always exciting to see new VPN services come onto the scene.
EDIT: Few things I forgot to mention - there needs to be more transparency about entry servers. If most or all wireguard configs aka devices are always 'double-hop' by design by having exit pools to choose from... where will these configs connect to initially? and is it always the exact same server? What country and therefore jurisdiction is this in? Also the ToS needs more clarity on the company and the country it is incorporated in. Hope you spin up a shell company in Switzerland or whatever! A lot of ppl will keep walking if there's no protections in that realm
Some questions:
Can you explain the intent here? 16 digits seems to be nowhere near the threshold that's viable for any user authentication in 2026, especially given "Your own devices on one account can still talk to each other, like a small private LAN.".
If you're not logging, how are you enforcing this? And relatedly, are you "logless" or do "traffic logs live in memory only and are scrubbed"?
Why wait?
yeah the account number is basically the mullvad model, 16 digits, no email no password. its a tradeoff, i know some people hate it. login is rate limited server side so you cant just sit there hammering numbers at it. is it weaker than a long passphrase? probably yeah. the flip side is theres no personal info sitting in a database for someone to leak, or for someone to show up with a subpoena for.
on the local network point, thats only your own devices seeing each other. traffic between different customers is blocked.
logs, our thing is reactive, we're not sitting there watching everything. we act when we get an abuse report. some of it is just blocked structurally anyway, port 25 is closed so no spam is coming out of there. and we keep zero logs. child abuse material, account gets terminated if we get a credible report or a legal notice, but we dont proactively scan, thats not really possible when the traffic is encrypted and theres nothing logged to scan in the first place. the only thing counted is aggregate bytes per account for the quota and the trial. not what, not where.
and honestly, this is a one person project. code needs cleanup, secrets and config need to come out, and it needs a proper security pass before its safe to publish.
The difference is that Mullvad doesn't enable any east/west connectivity at all. If somebody guesses a user's Mullvad 16 digit number, they can use Mullvad's services as that user. If somebody gets a SmokeVPN users's 16 digit number, they can connect to that user's other devices.
How would you take any action with an abuse report and no logs? You'd get a report or subpoena or similar that listed an egress IP and a timestamp and say "We need information on this user for this charge" or "You're ordered to halt this illegal traffic", and you'd not have any way to tie that out to a specific user retroactively. There are plenty of providers who take the stance that they don't log and thus effectively cannot prevent or restrict illegal or abusive activity. I'm just not understanding how you could claim to both be logless and restrict those things.
For completion, I decided to make device to device connections an opt-in feature that requires 2fa enabled to log into the account. AUP was also rephrased to make a clear distinction between prevention and identification.
You're right on both counts.
My Mullvad comparison was focused on the credential, not on the LAN model. Brute forcing the account was never the issue, I missed the point about device-to-device was the real threat, fair point. I'm starting implementing LAN connections as opt-in, not default.
Second point, you're also right, because I was mixing prevent and identify, preventions shouldn't need logs, we can't take an IP address and a timestamp and attach a user to it, and the AUP imply something else, I'll rephrase this.
I didn't mention on the original post, but the server currently has 84 exit servers in 45 countries.