On Fri, 2016-09-30 at 10:11 +0200, Jan Just Keijser wrote: > > I'm still grappling for the "killer use case" for this - yes, it would be > nice to implement support on all platforms for all > modes, **BUT** I don't think anybody actually uses 'topology p2p' at this > moment (because Windows clients don't support it - > catch 22). > How would client routing become easier in this case compared to 'topology > subnet' ? you will still need to set some routes on > the client side - all of which can also be set in subnet mode. > Also, in theory you don't have to put a client inside the server-side network > (/24) range in any mode - it's just a matter of > setting the right routing rules on both client and server, regardless of the > mode (net30, p2p or subnet).
It's not so much about the IP addresses you *do* want to route; it's more about the ones you *don't*. Let's say that for whatever reason (rehoming, connecting to another RFC1918 network with conflicting address ranges, whatever) I have a specific IP address like 192.168.0.95 which is for use on the VPN (and talking to selected hosts on that VPN). On Windows, the *smallest* netmask I can use with that IP address would be a /26. Because any narrower netmask would result in Windows refusing to configure it — on the basis that .95 would be the *broadcast* address for such a subnet. So now I have a /26 and I end up routing every IP address between 192.168.0.64 and 192.168.0.127 onto the VPN, when some of those might be IP addresses that I need to talk to on the *local* network. Sure, if you have completely free choice of IP addresses, you'd choose something else like 192.168.0.94 and then you *could* have a /30 and "only" waste three IP addresses for it. But maybe you can't. Or maybe even those three IP addresses are IP addresses we *really* need to talk to on the local network, not the remote. > Finally, in view of the fact that I seem to be the only one > responding to this thread, I'm afraid that not too many people are > getting enthousiastic ... Seems that way :) So my ulterior motive is this... I am using the TAP-Windows driver in a way which you don't. In the TAP_IOCTL_CONFIG_TUN ioctl I basically *ignore* the VPN netmask settings, and set both the network and mask to 0.0.0.0 as I described in my first message in this thread: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/95da6b6cd15d574 Then all the VPN routes can be added as On-link routes by specifying the interface index. I'd be *happier* if OpenVPN had a mode that used the driver this way too; then I wouldn't keep waking up in the night in a cold sweat, having dreamt that you broke it and I coudn't even ship a signed driver that makes it work again... I was hoping that saying "hey, you can fix your p2p mode which you document as broken on Windows for no good reason" would tempt you into actually doing it. Maybe it'll still work if I submit a patch myself to fix it. :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
