id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 682,Protect the client from accepting arbitrary options pushed by the server,chris.laif,,"I wonder if there is an easy way to protect the client from executing ifconfig/route-statements sent by an (untrusted) server. I think of some config options like ifconfig-limit 10.123.0.0/24 route-limit 10.111.0.0/16 route-limit 10.222.0.0/24 Any statements sent by the server not matching those networks would be ignored. I know the 'ifconfig-noexec' and 'route-nopull' options. That's what I'm using right now. In case of the 'route' statements it's kind of working, because in most of the cases I know the destination networks in advance. In case of 'ifconfig' it's not working, because in many cases the other VPN endpoint dynamically allocates my endpoint IP address from a class C pool. And I can not pick a fixed IP address, which might be allocated by some other user of the VPN now or later. My problem is, that the remote administrator might 'inject' arbitrary IP addresses/networks conflicting with my existing (local) network. He might do this by malicious intent or even by accident (renumbering his network, overlapping with other networks on our side). In our current setup, we have a 'VPN hub' connecting to 10+ partner networks. If any of the partners changes his network topology, this might clash with other partner networks. And no, unfortunately we can not negotiate fixed IP addresses with all of the partners. This is why I vote for implementing 'ifconfig-limit' and 'route-limit' statements or some other mechanism to protect our setup. -- Comment by Gert Doering (https://sourceforge.net/p/openvpn/mailman/message/35086118/): OK, I can see that in your setup (with multiple VPNs connecting to a hub, not ""just the client"") more tight control is desireable. I'm not promising anything - this is a fairly special-case request, and we already have sooo many special-case options that tend to get broken if we change other bits of the code - it should be able to implement these (route, ifconfig, ipv4 and ipv6) in a way that is not touched much by other code bits - and maybe we can even come up with a more general ""--pull-option-filter