Looking at it for a few minutes, this has some issues:
- symmetrical crypto with shared key across all clients, letting any VPN client act as any other client
- no PFS (straight AEAD with AES-GCM)
- alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
- home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
- static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
- no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
There's probably other things I missed, especially crypto-wise.
I'd stay away from this (at least for now) and use something like wireguard or tinc instead.
- symmetrical crypto with shared key across all clients, letting any VPN client act as any other client
- no PFS (straight AEAD with AES-GCM)
- alternatively, sketchy home-grown AES-CBC crypto that doesn't seem to be authenticated and as such allows for replay attacks and whatnot
- home-rolled SHA-1 pbkdf1 instead of stdlib pbkdf2 with a better hash
- static routing (ie. no way for a client to decide what prefixes to announce at a given time without updating the centralized config)
- no support for roaming clients like phones or clients behind NAT (currently just depends on being able to send UDP datagrams to a preconfigured remote address)
There's probably other things I missed, especially crypto-wise.
I'd stay away from this (at least for now) and use something like wireguard or tinc instead.