James Yonan wrote:
Well I think there's an important security principle at stake here. Namely that security software should, when configuration variations exist which are more or less permissive, default to the less permissive state unless explicitly configured otherwise by the admin. This is the principle behind (for example) having firewalls configured by default to block all incoming connections, until the admin configures them otherwise.
1000% agreed. I do the same thing here, all new systems that are on public IPs default to DROP for INPUT and FORWARD firewall tables until I've decided what to open up (on Linux, obviously).
Enabling client-to-client mode is more permissive than disabling it. This is why OpenVPN requires an explicit config file option to enable it and an explicit route push to set up the return routes.
I didn't see client-to-client as being more or less permissive, only an optimization. It's only more permissive if the server admin has set up forwarding filters between clients and then turns client-to-client on (which bypasses those filters). Unless the admin has set up forwarding filters, client-to-client is not any more permissive than client-to-server. If the admin _has_ set up forwarding filters and then turns on client-to-client anyway, they get to keep all the pieces (and the docs warn them not to do that pretty explicitly).
There is also the issue where you want to push a wider route to the client than is defined by the ifconfig pool range. For example, you might want something like this:
OK, I can see your point here. I was working from the point of view of not breaking up /24s into smaller subnets and using them this way, but I can see where if you need to do that then "automatic" route pushing could be a problem.
The other risk of always pushing the ifconfig-pool route to the client even if it's not needed is that it can break the client's network stack if the pool subnet conflicts with another subnet on the client. I personally experienced this once at a WiFi cafe which was using the same 192.168.x.x subnet internally as my VPN. Everything worked fine because my VPN subnet was very small, so it took priority in the routing table. But suppose that the server pushed a large, unnecessary route to my client that (say) was more specific than the local WiFi subnet (giving it priority), but that also blocked a critical address such as the WiFi default gateway?
Right. This would be a major snafu, although it can be somewhat worked around by adding a host route to the default gateway in the client's routing table (which I believe OpenVPN already knows how to do, although I've never needed it so I haven't paid much attention).
And to ensure this is always the case, OpenVPN does not push any routes unless explicitly asked to by either push route or push redirect-gateway.
True, client-to-client is an optimization of sorts, however the example in the release notes is essentially clients-only-see-server because it pushes a host route to the clients refering to the server's local tun endpoint, not the whole ifconfig-pool subnet:
In this example, if client-to-client is in effect, then the clients still won't be able to talk to each other directly because they won't have any route available for that traffic.
I will reword my suggestion then to ask that my example be documented as the "simple" way to set up server mode with ifconfig-pool and multiple clients. There are obviously many more advanced configurations, but for people just starting out if they don't push the routes as I suggested they will run into the same problems that I did and wonder why their network stack is dropping incoming packets (since there is no return route). As you mention above, this sort of configuration is only possible if the subnet being used for ifconfig-pool is not likely to be in use on the local network at the client's end, but I suspect that is not the most common arrangement.
____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users