Consolidate VPN & networking approach

[rikukissa]

Production setups of OpenCRVS should not be exposed to the public internet. If we assume there are countries who have nothing besides a VPS to install OpenCRVS on, what should our recommendations be for the following issues

Ideal scenario:
Government IT provides and manages a VPN client and credentials for all end-users of OpenCRVS. Implementation team receives an the source IP address from IT and it's used when defining requirements for data center level networking.

No Government provided VPN:
Implementation team installs Wireguard as per our reference implementation to either on their QA server or a dedicated VPS.

• What are the risks using QA as the VPN server?
• Is our current Wireguard server correctly configured and secure enough?
• Is wg-easy and its admin UI the right approach?

Firewalling not possible outside the VPS
@n1koo what's your take on how typical this would be in tier 2+ data centers?

• How would we hide the server so that it could. only be accessed through a VPN? Could we use Cloudflare for this and how much of that could be automated?

Current networking diagram

Source file: https://drive.google.com/file/d/1rJP6ZZxkL158cdtiZfLf5515M_cw2LhM/view?usp=drive_link

[n1koo]

Still working on this but to address some of the questions:

What are the risks using QA as the VPN server?
If we can assume the deploying parties at minimum have

• QA box
• Backup box
• Preprod box
• Prod boxes

Of these boxes QA (and probably also preprod) should be in separate networks. Preprod, depending on the usage, could have real data in it but ideally that would be masked/obfuscated.

QA however probably should never have non-masked data.

So if we think it from network/data access pov only QA is separated from prod data.

That said, QA will also have the most changes and most users. Which means that might be an environment where mistakes are made and access is wider -> more chance for someone to abuse.

So not great, but QA definitely is best of these options if a a dedicated VPN box doesn't exist.

[n1koo]

Is wg-easy and its admin UI the right approach?

wg-easy might cause us some headaches. Theres some limitations in its implementations that we need to either improve or workaround

Single client subnet (we need atleast 2, probably 3)

We can workaround this by running multiple instances but it seems clunky and maintenenace pain. Fixing it upstream is also likely somewhat involved.

Theres no easy solution to this but we need to dig bit deeper

Subnets for clients are hardcoded to /24 which means 253 usable IPs

@rikukissa mentioned we should probably consider 1000+ users. I didn't check the source code but very likely this is easy to fix upstream and we can contribute it to ensure we dont need to maintain a fork. Seems its already been asked by others wg-easy/wg-easy#140

[peterlewis]

Hey @n1koo! There's an open PR that aims to implement CIDR ranges in wg-easy over at wg-easy/wg-easy#797. Please do feel free to review and contribute, thanks! :)

[euanmillar]

@rikukissa @n1koo can we close this now as we have removed Wireguard in 1.5.0 ?