Disabling IPv6 when using VPN?

Got a problem with Viscosity or need help? Ask here!

viscous

Posts: 2
Joined: Fri Jan 02, 2015 9:25 am

Post by viscous » Fri Jan 02, 2015 9:35 am
Hello!

I have an older, ViscosityVPP edition that supports disabling IPv6 when the VPN is active. I cannot find that option on the non-branded version of Viscosity. Was it removed? Is it possible to be added back in?

I came up with the following workaround, but it feels very kludgy.

Before Connect:
Code: Select all
@echo off
REM disable ipv6 on ethernet
rem netsh interface ipv6 set interface ethernet routerdiscovery disabled
cd %USERPROFILE%\Desktop
start /wait powershell ./toggleipv6.ps1 disable
Disconnect:
Code: Select all
@echo off
REM enable ipv6 on ethernet
rem netsh interface ipv6 set interface ethernet routerdiscovery enabled
cd %USERPROFILE%\Desktop
start /wait powershell ./toggleipv6.ps1 enable
toggleIPv6.ps1
Code: Select all
# disable or enable ipv6
# read in command line arguments
Param
(
    #[Parameter(Mandatory = $true)]
    [string]$startstop
)

Write-Host "Looking to see if administrator..."

# check if administrator
# from: http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/09/23/a-self-elevating-powershell-script.aspx
# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)

# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
 
# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    Write-Host "We are an administrator!"
    switch($startstop)
    {
        enable
        {
            Write-Host "Enabling Router Discovery"
            Set-NetIPInterface ethernet -AddressFamily ipv6 -RouterDiscovery enabled
        }
        disable
        {
            Write-Host "Disabling Router Discovery"
            Set-NetIPInterface ethernet -AddressFamily ipv6 -RouterDiscovery disable
        }
        default
        {
            Write-Host "Invalid argument: $startstop"
        }
    }
}
else
{
    # restart with elevated privileges
    $cmdline = "$PSCommandPath $startstop"
    Start-Process powershell $cmdline -verb runas
}
You'll need to replace the "cd %USERPROFILE%\Desktop" with where you store the toggleIPv6.ps1 file. Right now Viscosity appears to copy the batch files for the VPN to the Roaming profile directory instead of leaving them where they are originally. (Side note, is this possible to change? i.e., leave the files where they are and just read them from that location?)

Note, this does not need to be run as administrator because the powershell script will self-elevate (with the UAC pop-up) as needed.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Jan 05, 2015 11:53 am
Hi viscous,

This feature has never been added to Viscosity, but it is on the list to be added in the future. The way the VPP edition blocks IPv6 is actually much more simple than this, it simply routes all IPv6 traffic to the loopback adapter (i.e. essentially sends IPv6 traffic to nowhere).

You can replicate this in Viscosity by adding the following routes to a connection (Edit your connection, go to the Networking tab and press the +):
The Gateway for all three should be ::1

Then for each:

Destination: 2000::
Mask: 4

Destination: 3000::
Mask: 4

Destination: fc00::
Mask: 7

Let us know if you have any problems.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

mrstanwell

Posts: 5
Joined: Wed Aug 15, 2012 7:36 am

Post by mrstanwell » Sun Aug 30, 2015 11:16 am
FYI, I just tried this on a Mac running OS X 10.8.5 (yeah, yeah… late adopter…), Viscosity 1.5.8, and PrivateInternetAccess VPN. When I bring up the VPN and try "ping6 google.com" to test, my system crashes and reboots. There're no messages in syslog or anywhere else for that matter. It's reproduceable every time. I'm well and truly baffled as to how an ICMPv6 packet can kernel panic OS X, but it seems there's some nassssty bugses somewhere… ;-)

PIA doesn't support v6. I'd like to be able to shut off v6 traffic when PIA is up. This approach seems like it would be simple and effective. However….

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Aug 31, 2015 4:52 am
Hi mrstanwell,

As the routes created don't involve the VPN connection at all I'd say the most likely culprit would be a third-party network driver or filter. If you have any firewall, anti-virus, networking, or other security software installed I'd recommend temporarily uninstalling it and see if you have the same problem.

You may also like to checking the "System Diagnostic Reports" section of the Console to see if there are any kernel panic reports for the crash you are seeing. If there are they should indicate the kernel extension or component responsible for the crash.
http://www.sparklabs.com/support/viewin ... nsole_log/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

mrstanwell

Posts: 5
Joined: Wed Aug 15, 2012 7:36 am

Post by mrstanwell » Fri Sep 04, 2015 2:22 pm
Hi, James...

Thanks for replying. I'm not running any 3rd-party network drivers/filters. The panic is in the system inet6 driver:
Code: Select all
panic(cpu 0 caller 0xffffff800cd7b442): assertion failed: ndi != NULL && ndi->initialized, file: /SourceCache/xnu/xnu-2050.48.19/bsd/netinet6/nd6.c, line: 3316
Now, if I bring up the VPN but add the route manually (route add -inet6 2000::/4 -gateway ::1), I get the expected behavior... ping6 google.com just times out. It's only when I set the route in Preferences->Networking for the VPN connection that I get the kernel panic.

Actually, I just noticed that when I set the gateway to ::1 in the Viscosity gui and bring up the VPN, the route table shows the gateway for 2000::/4 to be tun0, not ::1. That doesn't seem right. Any ideas?

Thanks!

Ron

rro

Posts: 2
Joined: Mon Sep 07, 2015 4:10 pm

Post by rro » Mon Sep 07, 2015 4:18 pm
Hi James,

I am also interested in disabling IPv6 traffic through Viscosity (build 1247) on OS X (10.10.5). When I enter the routes as described in the post in the connection Networking settings:
Screenshot 2015-09-07 16.13.14.png
Viscosity connection Networking settings
Screenshot 2015-09-07 16.13.14.png (67.23 KiB) Viewed 16662 times
and then try to execute `ping6 google.com` I get:

ping6: UDP connect: Invalid argument

also as outlined by the previous commenter, the routing table looks like follows:

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UHL lo0
2000::/4 utun0 USc utun0
3000::/4 utun0 USc utun0
f000::/4 utun0 USc utun0
...

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Sep 21, 2015 5:17 am
Hi Folks,
Actually, I just noticed that when I set the gateway to ::1 in the Viscosity gui and bring up the VPN, the route table shows the gateway for 2000::/4 to be tun0, not ::1.
It's possible that IPv6 may be enabled on the interface (even if OpenVPN isn't actually set up for it). It should however still be resulting in IPv6 traffic being blocked. I'm afraid the kernel panic looks like a IPv6 Mac OS X bug. Updating to a more recent version of OS X should do the trick.

Alternatively, if you want to setup the routes by hand or in a Connected script, I recommend the inclusion of the "-reject" flag. This will mean that even if a different gateway is used, IPv6 packets will be blocked. For example:
Code: Select all
sudo route add -inet6 2000:: -prefixlen 4 -reject ::1
sudo route add -inet6 3000:: -prefixlen 4 -reject ::1
sudo route add -inet6 fc00:: -prefixlen 7 -reject ::1
I am also interested in disabling IPv6 traffic through Viscosity (build 1247) on OS X (10.10.5). When I enter the routes as described in the post in the connection Networking settings:
It appears the Mask/Bits value for one of the entries is incorrect. Try fixing it up and see how you get on. We do have a full write-up of the steps in the following support article:
http://www.sparklabs.com/support/preven ... fic_leaks/

If you're still stuck you could also try using the scripting approach above instead.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

beachbuy

Posts: 1
Joined: Mon Sep 21, 2015 11:27 pm

Post by beachbuy » Mon Sep 21, 2015 11:32 pm
Guys, any idea what should be added in OpenVPN server's config. in order to disable IPv6 leak on client-side?
Would push "route-ipv6 2000::/3" be enough?

Thank you

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Thu Sep 24, 2015 10:02 am
Hi Beachbuy,

Chances are pushing ipv6 routes from the server won't work as OpenVPN will simply ignore them (or Windows won't set them) unless there is a valid IPv6 network setup for the VPN. This is something you will need to do from the client unfortunately.

You can try pushing routes I mention in my original reply, ensuring to also push them with gateway ::1, but you will need to test it extensively.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

mrstanwell

Posts: 5
Joined: Wed Aug 15, 2012 7:36 am

Post by mrstanwell » Fri Sep 25, 2015 5:48 am
Hi, James…
James wrote:
It's possible that IPv6 may be enabled on the interface (even if OpenVPN isn't actually set up for it). It should however still be resulting in IPv6 traffic being blocked.
Well, I get the same results whether or not IPv6 is enabled in Viscosity. And traffic is blocked, but for whatever reason the ping6 specifically triggers the panic.
James wrote:
I'm afraid the kernel panic looks like a IPv6 Mac OS X bug. Updating to a more recent version of OS X should do the trick.
Yeah, unfortunately you're right. I installed Viscosity into a VM I have running Yosemite, and there's no kernel panic.

Thanks…

Ron
10 posts Page 1 of 1