|
|
> However, I don't see how pushing a wider route to the client really > breaks any security. If the server doesn't have client-to-client turned > on, then it's up to the server administrator whether they allow traffic > between clients by using whatever filtering means they have on the > server. Also, the clients will not have _any_ way of knowing the IP > addresses of any other client's tunnel endpoints, because they are dynamic. 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. 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. 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: ifconfig 10.8.0.1 10.8.0.2 ifconfig-pool 10.8.0.128 10.8.0.255 route 10.8.0.128 255.255.255.128 push "route 10.8.0.0 255.255.255.0" where you want clients to be able to see machines on the server side between 10.8.0.4 and 10.8.0.127 in addition to the ifconfig-pool clients. The ability to succinctly express this sort of usage breaks down if you wrap the local ifconfig, local route, and route push functionality into ifconfig-pool. While you would be wrapping four commands into one, that one would be less flexible. 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? In general, it's almost always a bad idea to reconfigure the network stack (and that includes adding routes) more than is absolutely necessary to accomplish the given task. 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. > Not pushing a route out sounds like "security through obscurity", which > is no security at all. If the client is aware that the server is using > server mode with ifconfig-pool, they can certainly just add their own > route to the ifconfig-pool address range and start sending packets. If > the server admin is really concerned about this, they have to limit > client-to-client access in a positive fashion, not just rely on obscurity. I think you're misinterpreting the adage "security through obscurity". Typical usage refers to situations where weak security is masked by a lack of clear documentation, and where the cost of reverse engineering to expose the weakness is high. Open Source software really represents the antithesis of security through obscurity. > > I do agree with you that the release notes should be more clear about the > > distinctions between a client-to-client config and a clients-only-see-server > > config. > > I would disagree, I think the release notes are fine. OpenVPN does not > provide a "clients-only-see-server" config at all; even with > client-to-client off, the clients can still talk to each other by going > through the IP routing stack on the server. client-to-client only > provides a simpler, faster means for them to talk to each other. 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: # Push route to client to bind it to our local # virtual endpoint. push "route 10.8.0.1 255.255.255.255" The type of route (host vs. net) on the client of course does not, by itself, accomplish the security of having clients not be able to see each other -- only the server's network configuration can do that, such as a firewall rule on the server which drops all packets except those directed to the server's local tun address and/or the disabling of cross-interface forwarding. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |