Running PT VPN in AWS. I’m generally unhappy with running any HTTP service directly on the internet, and our security team has flagged this as a potential issue.
I’d like to attach a second network adapter to the instance, have the Web UI listen on that adapter only and serve that web traffic through a more secured channel.
Is this possible with Pritunl or does the web service always have to listen on the same adapter as the VPN service?
That won’t do anything to improve the security of the server. The bind_addr in /etc/pritunl.conf will control which network interface the web server binds to. There’s already extensive protections for the web server, more information is available in the security features documentation. Running sudo pritunl set app.web_systemd true will run the web server in a non-root process this will provide better isolation. The web server also has SELinux policies when installed on RHEL, Oracle Linux, AlmaLinux or Rocky Linux.
I think the problem being solved here is created by audits/certifications like the UK Cyber Essentials etc where you have to show that the admin interface is not public
I run the web interface through AWS WAF and only allow the url’s that the clients need.
All of the user/admin post/get requests are blocked if you are not on the internal network (or VPN)
This reduces self service ability (we have to send the profile url to new users manually) but we are required to block this unless a strong business case justifies it
We accept Pritnl may change the url’s in the future so we monitor the blocked requests
The client url’s I have picked up so far start with
/key/
/k/
key is the day to day updates to the wireguard keys , and k seems to be profile imports and updates
@zach confirmation of these would be great , eg Authentik list the admin paths that you can block on your WAF
There’s already a strong protection of the admin paths in the external pritunl-web process. This is done with a NaCl signature that pre-validates request before forwarding to the internal pritunl process. All the paths are listed in pritunl-web/handlers/handlers.go this can be used as a reference for path filters. All the authGroup paths are admin only. Most of the openAuth paths need to be open for connections or single sign-on. The /auth/session path is for initiating an admin login that can be blocked. The /link/state is only needed for pritunl-link.