Hello David, Thx for explantion of script usage.
DS> Well, I can agree to that. But this is all open source. No matter how DS> much restrictions you put into the openvpn product, the user can download DS> the source, add the features missing, and reconnect with a modified DS> OpenVPN version. ACK, if he has the complete configuration and all secrets. But in enterprise scenario the user has only a company configured machine and his own username/password or smartcard. For example tls-key could be unkown to user. The user can't boot his own machine, install patched openvpn and connect to vpn server because one secret is missing. That's the reason why I think openvpn shouldn't be started as an user and config must controlled from enterprise. Cisco introduced a stupid encryption of key material in .vcf. The user should be allowed to setup the tunnel on this own. User can take http://newgre.net/passwordrevealer and Shrewsoft Client to connect. All enforcements are gone (push redirect-gateway for example). DS> be code which is not easily available, so the client can't fake this DS> operation as well. ACK DS> Bottom line is, you can't fully control the client environment. You can't control the client from a VPN tool. You have to control the client in enterprise directly. Group policies, software restriction policies, good ACLs, etc. DS> What you can do on the client side, is to avoid a third party (think DS> virus/malware) to figure out that openvpn is installed, and tweak the DS> config to run code which was not supposed to be run with higher DS> privileges. Virus runs with user privileges, config is only modifiable with admin privileges. No problem. Virus can establish VPN connection, same like the user. DS> So the client should try to lock down things locally, to DS> reduce the impact from local exploits. Not the openvpn client but the complete machine. DS> There's no real way you can make the server enforce restrictions on the client. Full ACK greetings Carsten
