2. Would you consider supporting a json configuration file? The current Wireguard ini format has duplicate entires for 'Peers' and the python ini parser for instance does not support duplicate section heads.
3. While the allowed IPs construct is powerful it can sometimes feel a bit unintuitive. The way I understand it the 'AllowedIP config on the Wireguard server is for shared networks from the client and on the client for accepted networks. This is so the server knows where to route (and thus there cannot be duplicate IPs, subnets or any subnet overlapping in the server config) and the client can only receive traffic from acceptedips recorded on the client side config.
My mindset may be a bit too container orientated with hosts sharing internal container networks across systems at the moment, and Wireguard has a much broader use case but the share/accept construct seems slightly more intuitive though I could be wrong.
4. The Wireguard server is a single point of failure in a star topology. If the server host goes down your network goes down with it. How can we add more resilience in a simple way? A backup server in L2 with identical keys and a floating internal IP?
Thanks for Wireguard!
Raul