Am 17.08.2013 12:30, schrieb Gert Doering: > So, what I'm hoping to hear from you... > > - should we include this in 2.3.3? > - if yes, are changes needed?
Well, it would take huge warning banners because it might disrupt existing setups (which would be insecure through the "connect around tunnel" behaviour), so I'd prefer "2.4" with a sooner 2.4 release. > - should we try to implement something for 2.4/master that will work > by pointing the IPv6 routes into the tunnel, and then synthesize the > IPv6 ICMP errors inside OpenVPN? That would work on Android and iOS > as well, and remove the extra per-platform logic for the "reject" routes Absolutely, on both accounts, if technically feasible. You may need to synthesize RST for stale TCP sockets, and ICMP for UDP, too. > - any clever ideas how to achieve "full" IPv6 blocking (right now, it only > kills the default route, but all more specific routes continue working - > this is by design to keep the implementation simple, and was considered > "good enough" by the end customer asking for it) End users may also have requirements to override certain more specific routes to bypass the tunnel. I can fancy only few things that are worse than flipping global connection status "with/without VPN" every few minutes if you need host and "home" resources at the same time. Use case is for guests in a "host" LAN that need the VPN for the default route and "home" networks, but need to access local organizer (host) information, too. And very common during symposiums, conferences, and thereabouts. Like: you visit another place, and you need access to the journals of your home university, but at the same time the organizer uploaded documents for collaborative work or you need local public transport schedules. I found myself using the "permit local specific routes" switch quite often to avoid dis-/reconnecting all the time. That was with "all IPv4", however.
signature.asc
Description: OpenPGP digital signature
