User restrictions and permanent transfer

[xgusto]

I have 2 questions.

1. It would be possible to make the transfer not start from scratch after the reboot, but to continue with the values before the reboot.
2. Would it be possible to make the user see nothing but his account?

Username
  
Transfer: 59.49 KB TX, 187.75 KB RX
Latest Handshake: 11. 3. 2024 14:09:06
Endpoints: 87.65.43.21:34691
Allowed IPs: 10.0.3.3/32, 192.168.50.0/24

If it's not possible, that's okay.
Anyway, thank you for the best costume I've ever found

[eduardogsilva]

1- Yes and no!
Well, it's a bit complicated... The main issue here is that when wireguard is restarted, it just clears all the information from transfer, latest handshake and endpoints.

To facilitate troubleshooting, I made something similar to "latest handshake".
Every 10 minutes, the cron task would scan the latest handshake from all peers and write to the database.
When I load the peer list screen, if the latest handshake is 0, then I will load the stored latest handshake for that peer. This makes this information persistent across server reboots.

Making traffic consistent across reboots, would require something similar to this, but, with a lot more complications. I would at least need to track service restart and make the traffic for that service session permanent, and later combine with previous values. Also, when displaying the traffic in the web interface, I would need to always sum with the stored values. It's quite complicated and time consuming to make it right, but not impossible.

2- the wireguard_webadmin users are not designed to allow view/manage a specific peer (or group of peers) only. I can see 3 scenarios here:

A) creating an endpoint that would return a json (or html) information for an specific peer
B) creating an option to allow a call to api/wireguard_status/ with a token instead of user authentication (you could use this information to display to the user on your own system)
C) creating an extra option on the user to restrict view/manage to just some peers.

The option C) would introduce some unnecessary complications to wireguard_webadmin.
I can think about it, but maybe this customization is too specific for your case only.

Well, let me know what you are trying to achieve and tell me more about your use case. Maybe we can think something together.

Cheers

[xgusto]

It would be an interesting solution from the point of view of client statistics. However, if it is a lot of work, you don't have to waste your precious time on it. Your app is great anyway.

[eduardogsilva]

I'm glad you enjoyed!

I will leave this discussion open in case someone else have any input on this. :)

[xgusto]

Thank you for your work. These are just my bizarre requests. Maybe no one will have the same requirements as me.
BTW there are more important things. I wish you the best of luck in further development of the application.
We are glad that it is open source, because applications with such functions are mostly commercial.

[eduardogsilva]

@xgusto just to let you know that now it's possible to access /api/wireguard_status/ with an API key.
Head to #15 for more information ;)

[xgusto]

Thanks, I'll look into it tomorrow

[xgusto]

I updated to 0.9603 and accordingly /api/wireguard_status/?key=<your_uuid_here>
I see something like

{"wg0": {"TFNMF8qxxxxxxxxxxxxxxvJpA4BKFy0=": {"allowed-ips": ["10.10.3.2/32"], "latest-handshakes": "0", "transfer": {"tx": 0, "rx": 0}, "endpoints": "(none)"}, "r/O8t1rxxxxxxxxxxxxxxxxxxxBH4X86jUOHc=": {"allowed-ips": ["10.10.3.3/32 192.168.70.0/24"], "latest-handshakes": "1710355985", "transfer": {"tx": 10784, "rx": 2976}, "endpoints": "xx.xx.xx.xx:34691"}}}

I'm not a programmer, so I don't know what to do with it.
:-)

[eduardogsilva]

@xgusto this was the expected return from wireguard.
I wrote a small flask app showing how to consume this api endpoint and displaying peer information
Please check the announcement discussion: #15