Share some usage issues and suggestions, hoping to be resolved

[nhb2318]

Dear EduardogSilva：
Thank you very much for developing the wireguard_webadmin program, which makes it very convenient for us to use wireguard. I have deployed it and put in a lot of effort. I would like to communicate some usage issues or ideas with you now.

1. This Docker project is too large, occupying 1.7G. Do we really need such a large volume? Even servers with poor performance cannot run. Can you compress them to reduce the burden on the servers.
2. In the settings of Firewall, I don't understand what it means. Can you provide an explanatory document or give some examples to facilitate learning?
3. Can you put some parameters into the. env file, such as username, password, WGUI-SERVER-POST-UP_SCRIPT, WGUI-MTU, WGUI-PERSISTENT_KEEPALIVE, SERVERURL, etc.
4. I found that in the Server Settings interface, Post Up and Post Down are read-only and I cannot fill them in. I remember adding SCRIPT in the server settings, for example: iptables - A FORWARD - i% i - j ACCESS; Iptables - A FORWARD - o% i - j ACCESS; iptables - t nat - A POSTROUTING - o eth+- j MASQUERADE iptables - A FORWARD - i% i - j ACCESS; iptables - A FORWARD - o% i - j ACCESS; iptables - t nat - A POSTROUTING - o eth+- j MASQUERADE. Don't you need to add them to your program?
5. This is also the most important point I want to say. The User Manager has excellent functionality, but I suggest making further improvements. To achieve an effect, each user can only see their own Peers after logging in, hiding other Peers so as not to disrupt the network. Imagine if multiple users were connected to the same Peer network, wouldn't it be chaotic? Will it affect the network? So I suggest that when adding a Peer, you can set which user it belongs to, and then automatically filter out Peers that do not belong to the current user during loading, except for admin users.
   I hope to solve my problem. Thank you very much, and I will support you.

[eduardogsilva]

Hello @nhb2318 , thank you for your input. I will try to answer all your questions here

1. In fact, the image size is a bit larger. This is due to using a debian build instead of alpine. I will try to reduce this image size in the next releases. If you want a more complete discussion regarding the size of the build where I explain my design choices, you can check here 26.

Please note that the image size is not related to performance it just takes a bit more storage. In fact, wireguard_webadmin is VERY lightweight while running.

I have a wireguard_webadmin install running on a poor Digital ocean VPS with all the bells and whistles, including nginx, dns server and an extra cloudflare tunnel daemon.
This VPS is running totally idle. 1 core, with 0.00 CPU load and 261 MB of ram in use.

2. I do understand that the firewall page looks a bit challenging, but It's just a simplified interface for iptables. I would strongly suggest for you to take a crash course on iptables. As soon as you understand how it works, you will get this page pretty fast.
   I've also created a basic firewall guide here
   Anyhow, I will try to improve the documentation on this pages in the next releases to make it bit easier.

3. The parameters that you asked are already managed by the web interface.

• username/password -> those are created on the first access
• WGUI-SERVER-POST-UP_SCRIPT -> has been replaced by the new firewall
• WGUI-MTU -> In fact, I'm missing this setting here. I will add this field to server configuration page.
• WGUI-PERSISTENT_KEEPALIVE -> it's already on each peer configuration page.
• SERVERURL -> the public address that will be used on the client configuration is on server settings page.

4. this postup/postdown scripts are deprecated. this functionality was moved to the Firewall page. Instead of manually creating iptables rules here, you can use the web interface for that. I left this fields, so the users can check their previous firewall postup/down scripts. Those fields will probably be removed soon.

5. wireguard_webadmin is not intended to allow the "end user" to access the interface. The idea of the user manager feature, is allowing to share access to your staff members (with different permissions) so they can help to manage and troubleshoot your VPN server/clients. If you need a status page or other information for your clients, you can use the API for displaying this information. I have documented and even created a small flask application that shows the user information. You can check it here. (Maybe you will need a programmer to improve that flask application to fit your needs).
   Can you please share your use case, so I can understand how you intend to offer the web interface for your end users?

It took a while, but I believe that I answered all your questions.

Please let me know if you need something else!

Cheers!!

[nhb2318]

Thank you for your reply!
Regarding the fifth question, regarding the issue of refining permissions, let me give an example. For example, in our department, I developed an application system that our colleagues often use on business trips. However, without a public IP address, the application cannot be accessed from the external network. I have come up with many solutions for this matter. I have used FRP、 Zerotier、N2N、NPS， The best one to use is Zerotier, which has a simple and easy to understand settings interface. The only drawback is that it does not support domain names. During deployment, a Planet file will be generated based on the server IP address. Each client needs to import this Planet file to connect to the network. If my public IP changes, the Planet file will become invalid, which is very inconvenient. However, Zerotier's drilling speed is very fast. FRP is not P2P and is not recommended for use. N2N does not have a decent settings interface and does not support DHCP address allocation. Often, two users use the same virtual IP address, causing the entire network to crash. NPS is also a good penetration tool. Currently, I only use TCP penetration and haven't tried P2P because its client app isn't doing very well. So I chose WG and I am quite satisfied, although the speed is not as fast as Zerotier. Okay, let's get back to the point. Let's talk about the issue with the WG interface.
Our department has a large number of people who work together in different locations, so we need to use WG's virtual network. For example, I created 40 wg clients and we have 20 colleagues, each using two, one for laptops and one for smartphones. I have not experienced downloading 40 conf configuration files separately and distributing them to each of their respective individuals. So they need to download it themselves. After logging in with their own account, they can download their own conf configuration file or scan the QR code.
For example, if I create 4 new wg client:A. laptop, A. phone, B. laptop, B. phone, and also create two users A and B. If I log in as A user, A user can only display and download A. laptop. conf and A. phone. conf, and A user is not allowed to see B. laptop. conf and B. phone. conf. Only when each person correctly uses their own configuration file can administrators see the most realistic internet situation in the backend management interface. I haven't tried scanning a QR code on both phones using the same virtual IP, what would happen.
A suggestion is to add an option defined as "belonging to user" when creating a new client. If user A is selected, it can be displayed and downloaded after user A logging in, while other users will not be displayed after logging in.

[eduardogsilva]

Hello again @nhb2318 thanks for sharing your use case.

It's not the first time that someone asks for this.
I will evaluate this during the next week.

I've created an issue here: #29

I can't promise that it will be implemented, but I will take a closer look of how it can be done securely.

Cheers!

[nhb2318]

Thank you! Just add a field called "Belonging User" in the Peer information, and then add filtering conditions in the User CLIENT interface. Looking forward to your good news, rest early and pay attention to your health!

[eduardogsilva]

Hey @nhb2318 if you are still around, I would like to let you know that I just implemented a user-specific peer visibility feature.
#47

Cheers!