On Mon, 2016-09-26 at 13:34 +0200, Jan Just Keijser wrote: > > this sounds like a typical use case for "assign a public IP address". > This is already possible with topology subnet and some special config > stuff on the server side, e.g. > - give the openvpn server an IP range that overlaps with existing > (server-side) IP space > - don't assign address from a large DHCP pool, but use a client-connect > script to assign an address per certificate > - use proxy arp and some routing tricks to ensure that all client > traffic is routed properly via the server.
Ewww! But OK, yes I suppose that can work i most cases — at least for the server's routing. It still leaves the client routing more than it should down the VPN, and for some client IP addresses like x.x.x.127 you end up needing much more than a /30 — Windows won't let you have that IP address on the client side unless you use a netmask wide enough that it wouldn't be the broadcast address, so you have to send a whole /24 down the VPN from the client. When you only actually wanted *one* IP address to be routed that way. An IP address which might not even be in even that /24 subnet, in the general case of a p2p setup. > the one thing I'm afraid of with your new type of p2p addressing is that > we'd introduce yet-another topology system: net30, "old" p2p, subnet and > now "new" p2p - or would this simply be an extension of the never-used > "old" p2p topology? It wouldn't even be "an extension". It is *precisely* the original p2p mode. It would simply be a case of "this never used to work on Windows; now it does". -- 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
