Am 17.08.13 12:30, schrieb Gert Doering:
I am in favour of this. There is also another VPN breakage that could be adressed by this. Sometimes the apps try use old sockets until they are getting a timeout. RST/icmp unreable for packets with a wrong source IP could be handled as well.Hi,there's situation where you have a dual-stack IPv4+IPv6 client (like "most new end user connections in Germany these days"), and an IPv4-only OpenVPN setup - for whatever reason, like "running on an commercial system that is not using 2.3 yet" or the like. Trying to access corporate resources in such an environment can be problematic if the resource has IPv4+IPv6, but your tunnel only has IPv4 and your client prefers IPv6 - it will try to connect "around" the tunnel, leading to a number of undesirable effects. For the commercial OpenVPN client, I've hacked together something that mitigates this effect, by effectively breaking IPv6 connectivity while OpenVPN is running (so clients fall back to IPv4, which works through the tunnel). The option is called "block-ipv6", and currently works by setting up "reject" routes that immediately cause an ICMP unreachable to be sent when a client tries to connect to an IPv6 destination. This works nicely on Linux, MacOS and Windows, and should work on other BSDs as well (not implemented yet). It does not work on Android or iOS, as you have no control over the real routing table, just the "routes into the VPN" - while those would prevent IPv6 communication "around" the VPN tunnel, it will have the not-so-nice property of causing client *timeouts*, instead of fast aborts due to immediate ICMP errors. So, what I'm hoping to hear from you... - should we include this in 2.3.3? - if yes, are changes needed? - 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
Arne
smime.p7s
Description: S/MIME Kryptografische Unterschrift
