While I like the layout and having a good UI for managing virtual machines this project lacks any security features at all.

Most notably, if you just set the auth cookie to "authenticated" you will have access to spin up as many VMs you like on any flint instance in the wild (08-09-2025).

As such this is an incredibly unsafe project to use. Probably because of the vibe coding :(

Vibe coding by itself isn't a problem.

The problem is vibe coding AND negligence. Good software practices like testing, code review, documentation are bound to catch the LLM-isms.

No offense on the author, the project specifically calls out that it's a "young" project in the footer, so I personally wouldn't expect it to be quite up to spec yet.

Howdy folk!

After showing off my most recent project (Wag) I thought I'd pop reverse ssh (or RSSH) up here as well.

I've been tinkering with RSSH for 3 or so years. Starting with the incredibly dumb idea of going "I want ssh, but in reverse" i.e to connect back to me rather than me connecting to a port.

So lo' and behold RSSH came into being! Effectively, it allows you to deploy a single, statically compiled binary to pretty much any platform that go supports (including windows), and get all the nice features of SSH. And bonus! No need to open ports, or fight service providers, just execute and connect.

This project has shown me what an awesome protocol SSH is, both from its flexibility and extensibility which I regularly (ab)use.

Feel free to ask questions or ask for features!

Ironically I've also been thinking about this on and off for a bit, as it is definitely one of the pain points of using Wag at the moment.

My only problem is that if you capture that route and then redirect it, or whatnot, your peers wont be able to log in to wifi in public areas like coffee-shops/libraries/etc because the route will be trying to go via a VPN which wont be returning any real data.

Such as where you should be going to log in haha

Should be doable using FwMark and routing policy / nft rule?

So you'd put a fwmark on the interface , allowing you to route the VPN traffic separate from the traffic that should go over it. Then you have some mechanism to trigger when VPN is down. Curl someplace dedicated which also has a routing exception to go outside the tunnel. Detect captive portal IP. Add route (and clean up, like when online or switching).

Detecting captive portals re-establishing is a separate, but linked issue. It's mostly solved too.

Setting aside a VPN client, your browser and/or OS will send out a http get request to a site which returns "OK" or "success". If it returns a redirection, then it will go "ahha I'm behind a captive portal" and pop up a page for you to log in.

VPNs do something similar. The MozillaVPN client for example will periodically check for reauthentication by doing a http call over the non-VPN route to a server and looking for a response saying "success". If it needs a redirect it flags up a message on the client to disable your client and reroute traffic via normal networking to allow reauthenticaiton.

What I want from a wireguard client is it to check for captive portals outside (in a situation I'm routing the entire of 0.0/0 via wireguard), but also check for reachability inside the tunnel. Have "check" and "checktime" parameters, which poll a given server (presumably via the tunnel) preset a popup to reauthenticate.

Oh wag doesnt use username and password auth by default. Those are only available in the OIDC integration or if you use PAM auth.

Similar in terms of it uses wireguard definitely! I havent made a direct comparison in the documentation as it's not something I'm currently going toward. This project suits my needs and is quite fun!

But I'll try and give a basic run down on the differences/similarities.

Wag is good for hub and spoke design where you want to have a hard boundary, rather than a tailscale-esque mesh where everything touches everything and then the rules define the overlay.

Both wag and tailscale add SSO integrations and effectively 2FA for securing your users.

And both of us have a way to enroll and a web UI to manage things, although I'm sure TailScale is much more polished considering I'm one guy who doesnt like web development.

As for things Im definitely not going to implement, probably interception or a TLS proxy to redirect users once their session logs out. Primarily just because doing that in eBPF is a little bit beyond me right at this second, and I dont feel like writing the DNAT/SNAT components I'd probably have to in order to get it working

Welp, I have no idea if anyone will read this as its been a little while since it was put up and is in a flagged comment, but hey I'll do a lil explanation of some of the issues I ran in to, and how it works.

How it works:

In short, Wag adds an eBPF program to a WireGuard device that it instantiates. The eBPF program uses a number of hash maps and LPM (longest prefix matching trie) maps to determine the policies that are applied traffic coming in on the wireguard device. These policies based on the ACLs defined per user/group, and contain MFA/Allow/Deny rules which require mfa, allow without auth and deny always respectively.

Wag also watches all the wireguard peers ingress IP addresses, and when an address changes it deauthenticates the user and requires the user to complete a login challenge. This is done by basically setting a bit in the maps exposed to eBPF that says "unauthorised"

Challenges:

First and foremost with WireGuard there is no good way of determining if an "external ip" i.e where the user is connecting from has changed. There was a patch set submitted for review in 2022~ that was never actually added to the kernel that would have added netlink compatibility and thus event based notification that things had changed, but alas that was never reviewed by Jason Donenfeld and has quietly died the death.

Secondly was defining multiple policies per route was quite difficult as eBPF doesnt do dynamic memory even in userland exposed maps and I wanted multiple rules per route, i.e you might allow port 80/tcp when MFA has passed but otherwise always allow 22/tcp. So to do that I had to define a maximum number of rules that could be inserted as one memory blob into the LPM map that the ebpf program would then linearly search to make its decision.

Thirdly has been making everything highly available which has been a bit of an on-going battle with ETCd mainly around how it manages cluster certificates as they dont (as of 2024 but it may be coming soon) expose the right structures to allow for dyanmic certificate creation, so you have to kind of make a wrapper around that in order to get everything going.

Im sure there are other things that I've had struggles with, but these are what come to mind immediately!

Thank you for posting this. These are the types of details that you just don’t get unless the author has really worked through these issues in depth.

Best of luck with the project!

Thanks! It's been a bit of a labor of love for quite a while, these are the big three but there are a bunch of other little things.

Like the time I had to optimise map insertion because the linux kernel does some truly insane locking when you use specific types of eBPF maps:

https://github.com/NHAS/wag/issues/84

This is slated to be improved (or has already been improved in kernel 6.8?). But for now wag sort of just side steps it in a horribly stateful way.

Ooh, this looks cool! I'm mildly curious given Windows apparently is adding support for eBPF whether you could also get this running on Windows as well.

On the patch, maybe try reposting it on the list, with the pointer to your project to see if that provokes a new review?

Haha, me and a friend were both looking at the windows eBPF project and wondering if it might work. Im not really looking to support windows, but if someone comes to me and tells me it works I'll pop it on the read me

Ah the readme is definitely more geared to "how can I use this" rather than "how does this work.

Primarily because I want people to have a reasonably good time setting it up, rather than having to go through my explanation on things!

Man Deguard definitely looks slick and the UI looks really nice!

I'd be super interested to know how they track "session state" as their do seem to rely very heavily on adding proxies and other additional software layers in front of the wireguard connection itself (https://defguard.gitbook.io/defguard/admin-and-features/wire...)

With wag specifically it's all just wireguard and a tiny bit of ebpf to do the management, along with tracking the external IP to determine if its time to re-challenge a user.

I do plan on supporting IPv6 sometime soon, and doing something along the lines of mapping folks IPv4 addresses into private IPv6 space to reduce the risk of clashing with a users real local network.

Is there something specific you were thinking about when you mention ULAs?

Yep! I do indeed have protections against bruteforcing TOTP codes, effectively each authentication has a number of "attempts" a user can make before their account gets locked, and an admin is then required to unlock it.

Specifically to force people to have a bit of a think as to why their device is trying to force auth to begin with, as it indicates an endpoint compromise.