Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: Gert Doering <gert <at> greenie.muc.de>
Subject: RFD - block-ipv6
Newsgroups: gmane.network.openvpn.devel
Date: Saturday 17th August 2013 10:30:07 UTC (over 5 years ago)
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

 - 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)

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                          
//www.muc.de/~gert/
Gert Doering - Munich, Germany                            
[email protected]
fax: +49-89-35655025                       
[email protected]
 
CD: 17ms