How to limit admin panel to private ip?

cinnaroll

I've installed an OpenVPN Access Server on an Amazon EC2 instance. Everything seems to work fine but if possible I want to restrict the access to admin panel to the private ip that is connected to assigned elastic IP. A tutorial I've watched suggests doing this by unchecking Service Forwarding options under Server Network Settings. However that doesn't seem to do anything, the panel is still accessible via public IP. Is there a way to fix this?

The Johan

On Amazon EC2, your instance only has a private IP. Amazon's systems redirect all incoming traffic on the public IP address to that private IP address.

So, restricting access to that private IP address is just not going to work when you have an Elastic IP tied to it. Unless you are able to add a second private IP address to your instance that isn't tied to an Elastic IP.

cinnaroll

I see. I'm a total beginner when it comes to OpenVPN- would you consider leaving admin panel on the public IP a security risk?

The Johan

Only if you use very bad passwords. It has an automatic lockout system in place to prevent bruteforcing.

If you like, though, you can set the Admin UI to a different TCP port. That leaves the Client UI still working and the Connect Client will work properly then, but separate the Admin section to another port. If you set it for example to port 1234 then you have to access it like so: https://yourserver.address.com:1234/ (drop the admin part of the URL - that only happens when both Client UI and Admin UI are running on the same port). Be sure to disable service forwarding for the Admin UI.

Then, using security groups in Amazon's management panel, you can allow only certain IP addresses and ranges access to the Admin UI on port TCP 1234.

cinnaroll

Good idea! Thanks for the advice.

The Johan

It's only one of a multitude of possibilities. You can also add a dummy adapter to your system and assign a unique private IP to it and have the Admin UI listen there, and give access to certain VPN users to that IP. Then it won't be accessible from anywhere but through a VPN connection.

saliency

novaflash wroteIf you like, though, you can set the Admin UI to a different TCP port. That leaves the Client UI still working and the Connect Client will work properly then, but separate the Admin section to another port. If you set it for example to port 1234 then you have to access it like so: https://yourserver.address.com:1234/ (drop the admin part of the URL - that only happens when both Client UI and Admin UI are running on the same port). Be sure to disable service forwarding for the Admin UI.

What are the exact steps to do this?

tcaetano

what i did to solve this was blocking the port 943 (used for admin) from outside traffic.. just the lan could access it.. just use the security group to do that and you should be fine

nullsteph

Perhaps I missed something but changing the port still leaves the Admin to respond on 443 which has to remain open to all IPs in order to function.

The Johan

The client web interface and the admin web interface are 2 different things and by default run on the same port (943) and are shared through the TCP OpenVPN daemon at port TCP 443 as well. If you disable admin UI port sharing in the server network settings page, that last part gets disabled for the admin UI so the admin UI can only be reached through port TCP 943. If you also put the admin UI on a different port from the client UI, you can further separate them and define firewall rules to block access to one or the other.

It is recommended to leave at least the client web UI reachable through the TCP openvpn daemon. The settings are all in the server network settings page. If you mess with it, and you make a mistake, you can lock yourself out of the web interface. So have a backup ready or read documentation on how to change these settings via the command line to recover from mistakes.

marie-dk

novaflash wrote The client web interface and the admin web interface are 2 different things and by default run on the same port (943) and are shared through the TCP OpenVPN daemon at port TCP 443 as well. If you disable admin UI port sharing in the server network settings page, that last part gets disabled for the admin UI so the admin UI can only be reached through port TCP 943. If you also put the admin UI on a different port from the client UI, you can further separate them and define firewall rules to block access to one or the other.

It is recommended to leave at least the client web UI reachable through the TCP openvpn daemon. The settings are all in the server network settings page. If you mess with it, and you make a mistake, you can lock yourself out of the web interface. So have a backup ready or read documentation on how to change these settings via the command line to recover from mistakes.

I added rules to UFW to prevent access to the admin panel from the outside world. Then discovered that iptables i overruling my UFW config.

I then changed the ports for both admin and client GUI, and edited the UFW rules to reflect that change... Just to discover that OpenVPN AS also added the new ports to iptables leaving these new ports open to the outside world as well.

So it seems that the only way to prevent public access - if you (like me) is not comfortable mangling with iptables - is to have the GUIs listening to the local network only.

I strongly recommend that this inappropriateness is fixed in OpenVPN AS. People who value security may not appreciate revealing certain services to the public.

peterlecki

novaflash wrote I strongly recommend that this inappropriateness is fixed in OpenVPN AS. People who value security may not appreciate revealing certain services to the public.

I second that recommendation. Now I have to lose a feature to close this hole. I have to block the admin port from outside. Although downloading client software is also done on that port. But I have to block this for security. It's a side-effect of patching that hole.