IPv6 Windows client problems?

none577

My OpenVPN server is running on a DigitalOcean VPS that runs Ubuntu Linux and uses IPv4 addressing. I also run Ubuntu Linux at home. My ISP is also IPv4 and have no issues connecting with my VPN from my home computer. However, I've run into some issues when connecting an IPv6 Windows client to my VPN.

At first, I believed this was just a misunderstanding of the Windows client on my part. So, I booted up my Windows VM on my home Linux machine and ran through the setup again. And, lo' and behold it works perfectly. This leads me to believe that this is some kind of issue with the other client's IPv6 address.

Ideally, I want the client's IPv6 address to be masked by an IPv4 address (the server's address). However, as it stands the client's IP remains the same even when connected to the VPN. However, pinging my VPN "router" works just fine so I know it's connected properly.

How can I configure either the client or the server (or both) so that my IPv6 client effectively receives an IPv4 address?

Note: This is my first time dealing with IPv6, so I'm sure there's some caveat that I'm not aware of here.

Server config:

port 1194
proto udp
dev tap
up "/etc/openvpn/up-dns.sh"
ca ca.crt
cert vpn.crt
key vpn.key  # This file should be kept secret
dh dh1024.pem
server 10.22.29.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
status openvpn-status.log
log         openvpn.log
verb 3

Linux client config:

client
remote ***.***.***.***
ca /home/****/****/****.crt
cert /home/****/****/****.crt
key /home/****/****/****.key
comp-lzo yes
dev tap
proto udp
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nobody
group nogroup
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Windows client config:

client
remote ***.***.***.***
ca "C:\\Users\\Virtual Machine\\Desktop\\****.crt"
cert "C:\\Users\\Virtual Machine\\Desktop\\****.crt"
key "C:\\Users\\Virtual Machine\\Desktop\\****.key"
comp-lzo yes
dev tap
proto udp
nobind
auth-nocache
script-security 2
persist-key
persist-tun

Traffic

Probably going to need your logs as well please ..

none577

Here is a log from a working connection:

Sat Jan 31 04:49:42 2015 68.103.113.39:59224 TLS: Initial packet from [AF_INET]68.103.113.39:59224, sid=cee23e4d 212e0bbe
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 VERIFY OK: depth=1, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=vpn.nebulaseven.org, name=VPN, emailAddress=metaversal@nebulaseven.org
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 VERIFY OK: depth=0, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=Metaversal, name=Metaversal, emailAddress=mail@host.domain
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 31 04:49:43 2015 68.103.113.39:59224 [Metaversal] Peer Connection Initiated with [AF_INET]68.103.113.39:59224
Sat Jan 31 04:49:43 2015 Metaversal/68.103.113.39:59224 MULTI_sva: pool returned IPv4=10.22.29.2, IPv6=(Not enabled)
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 send_push_reply(): safe_cap=940
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 SENT CONTROL [Metaversal]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.2 255.255.255.0' (status=1)
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 MULTI: Learn: 00:ff:db:66:86:3a -> Metaversal/68.103.113.39:59224
Sat Jan 31 04:54:09 2015 Metaversal/68.103.113.39:59224 [Metaversal] Inactivity timeout (--ping-restart), restarting
Sat Jan 31 04:54:09 2015 Metaversal/68.103.113.39:59224 SIGUSR1[soft,ping-restart] received, client-instance restarting

And here is a connection from the problematic IPv6 client:

Sat Jan 31 04:13:41 2015 24.130.66.2:63781 TLS: Initial packet from [AF_INET]24.130.66.2:63781, sid=f8a02427 643889dd
Sat Jan 31 04:13:42 2015 24.130.66.2:63781 VERIFY OK: depth=1, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=vpn.nebulaseven.org, name=VPN, emailAddress=metaversal@nebulaseven.org
Sat Jan 31 04:13:42 2015 24.130.66.2:63781 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Nebula Seven, CN=Mistreskitty, name=MistresKitty, emailAddress=mistreskitty@nebulaseven.org
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 31 04:13:43 2015 24.130.66.2:63781 [Mistreskitty] Peer Connection Initiated with [AF_INET]24.130.66.2:63781
Sat Jan 31 04:13:43 2015 Mistreskitty/24.130.66.2:63781 MULTI_sva: pool returned IPv4=10.22.29.3, IPv6=(Not enabled)
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 send_push_reply(): safe_cap=940
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 SENT CONTROL [Mistreskitty]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.3 255.255.255.0' (status=1)
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 MULTI: Learn: 00:ff:8e:90:b3:77 -> Mistreskitty/24.130.66.2:63781
Sat Jan 31 04:19:00 2015 Mistreskitty/24.130.66.2:63781 [Mistreskitty] Inactivity timeout (--ping-restart), restarting
Sat Jan 31 04:19:00 2015 Mistreskitty/24.130.66.2:63781 SIGUSR1[soft,ping-restart] received, client-instance restarting

none577

Maybe my last post didn't make it through? Here are logs from a successful connection from my end as well as a faulty connection from the problematic end. I did a little more investigation (mind you, I do not own the problematic computer) and it looks like the ISP is a dual IPv4/IPv6 provider. Therefore, the troublesom computer in fact has two IP addresses (one IPv4, one IPv6).

Successful connection:

Sat Jan 31 01:43:28 2015 68.103.113.39:47335 TLS: Initial packet from [AF_INET]68.103.113.39:47335, sid=9c9c7fd1 d168f737
Sat Jan 31 01:43:29 2015 68.103.113.39:47335 VERIFY OK: depth=1, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=vpn.nebulaseven.org, name=VPN, emailAddress=metaversal@nebulaseven.org
Sat Jan 31 01:43:29 2015 68.103.113.39:47335 VERIFY OK: depth=0, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=Metaversal, name=Metaversal, emailAddress=mail@host.domain
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 31 01:43:30 2015 68.103.113.39:47335 [Metaversal] Peer Connection Initiated with [AF_INET]68.103.113.39:47335
Sat Jan 31 01:43:30 2015 MULTI: new connection by client 'Metaversal' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Sat Jan 31 01:43:30 2015 MULTI_sva: pool returned IPv4=10.22.29.2, IPv6=(Not enabled)
Sat Jan 31 01:43:32 2015 Metaversal/68.103.113.39:47335 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 31 01:43:32 2015 Metaversal/68.103.113.39:47335 send_push_reply(): safe_cap=940
Sat Jan 31 01:43:32 2015 Metaversal/68.103.113.39:47335 SENT CONTROL [Metaversal]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.2 255.255.255.0' (status=1)
Sat Jan 31 01:43:32 2015 Metaversal/68.103.113.39:47335 MULTI: Learn: 46:b9:7c:4a:2e:bd -> Metaversal/68.103.113.39:47335

The troublesome connection:

Sat Jan 31 03:39:17 2015 24.130.66.2:50885 TLS: Initial packet from [AF_INET]24.130.66.2:50885, sid=80bc6b52 cf8a4892
Sat Jan 31 03:39:18 2015 24.130.66.2:50885 VERIFY OK: depth=1, C=US, ST=NY, L=NewYork, O=Nebula-Seven, OU=VPN, CN=vpn.nebulaseven.org, name=VPN, emailAddress=metaversal@nebulaseven.org
Sat Jan 31 03:39:18 2015 24.130.66.2:50885 VERIFY OK: depth=0, C=US, ST=New York, L=New York, O=Nebula Seven, CN=Mistreskitty, name=MistresKitty, emailAddress=mistreskitty@nebulaseven.org
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 31 03:39:19 2015 24.130.66.2:50885 [Mistreskitty] Peer Connection Initiated with [AF_INET]24.130.66.2:50885
Sat Jan 31 03:39:19 2015 Mistreskitty/24.130.66.2:50885 MULTI_sva: pool returned IPv4=10.22.29.3, IPv6=(Not enabled)
Sat Jan 31 03:39:21 2015 Mistreskitty/24.130.66.2:50885 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 31 03:39:21 2015 Mistreskitty/24.130.66.2:50885 send_push_reply(): safe_cap=940
Sat Jan 31 03:39:21 2015 Mistreskitty/24.130.66.2:50885 SENT CONTROL [Mistreskitty]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.3 255.255.255.0' (status=1)
Sat Jan 31 03:39:21 2015 Mistreskitty/24.130.66.2:50885 MULTI: Learn: 00:ff:8e:90:b3:77 -> Mistreskitty/24.130.66.2:50885

Ultimately, it looks like the connection succeeds without problem. However, when I enable the VPN on the trouble computer and then navigate to, say, Google and enter "my ip" it still shows up as the real IPv6 address. So, for some reason the requests are still being routed through the real connection it looks like.

Traffic

From your server side log snippets:

none577 wroteHere is a log from a working connection:

Code:
...
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 SENT CONTROL [Metaversal]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.2 255.255.255.0' (status=1)
Sat Jan 31 04:49:46 2015 Metaversal/68.103.113.39:59224 MULTI: Learn: 00:ff:db:66:86:3a -> Metaversal/68.103.113.39:59224
Sat Jan 31 04:54:09 2015 Metaversal/68.103.113.39:59224 [Metaversal] Inactivity timeout (--ping-restart), restarting
Sat Jan 31 04:54:09 2015 Metaversal/68.103.113.39:59224 SIGUSR1[soft,ping-restart] received, client-instance restarting

This connection does not look like it is working ?

none577 wroteAnd here is a connection from the problematic IPv6 client:

Code:
...
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 SENT CONTROL [Mistreskitty]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-gateway 10.22.29.1,ping 10,ping-restart 120,ifconfig 10.22.29.3 255.255.255.0' (status=1)
Sat Jan 31 04:13:45 2015 Mistreskitty/24.130.66.2:63781 MULTI: Learn: 00:ff:8e:90:b3:77 -> Mistreskitty/24.130.66.2:63781
Sat Jan 31 04:19:00 2015 Mistreskitty/24.130.66.2:63781 [Mistreskitty] Inactivity timeout (--ping-restart), restarting
Sat Jan 31 04:19:00 2015 Mistreskitty/24.130.66.2:63781 SIGUSR1[soft,ping-restart] received, client-instance restarting

This connection also does not look like it is working ...

Title:

Re: IPv6 Windows client problems?

You are not providing any IPv6 support ?

IPv6 Related Options

Note: IPv4 is required for OpenVPN end points, at this time IPv6 cannot be used without IPv4.

I suggest you make sure your IPv4 VPN works before you try to tackle IPv6.

Next step: Post client logs ..

none577

I assure you it does work (at least from the successful clients), those are just disconnect notices. I only connected for short periods of time to test that it was working. I am intentionally not providing outgoing IPv6. Firstly, my OpenVPN server's host doesn't provide it. More importantly though, there are specific websites that need to be accessed that apparently don't recognize IPv6 addresses and fail to load properly (they use an IP-based database the probably doesn't support IPv6). Therefore, I'm trying to provide an IPv4 address to my IPv6 client so that these websites may be accessed.

I did a little more research on the problematic computer and OpenVPN is successfully assigning the correct IPv4 address for the VPN. However, it appears that traffic is still perferring IPv6 for some reason. I'll have a look at that link you posted and see if it helps to answer anything...

none577

Hm, so I just had an idea I suppose. If I were to provide IPv6 addresses on my VPN as well, wouldn't this then assign an VPN-specific IPv6 address to the client, effectively overriding their default? This might solve my problem I suppose. I'll look into setting an IPv6 subnet on OpenVPN to see if this works.

none577

I got IPv6 succesfully working via the VPN. I also am able to successfully get the addresses assigned to the client. However, for some reason IPv6 taffic is *still* routing through the WLAN connection and not through the VPN. While pinging an IPv6-enabled website such as Google returns the IPv6 address rather than IPv4. Doing a tracert to a non-IPv6 location, however *does* go through the VPN. Here is the routing and ipconfig information from the troublesome client:

Additions to my server.conf

server-ipv6 fd10:2229::/64

(note, I'm not pushing routes because I'm not looking to network the computers attached to the VPN)

Routing table

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.0.1         10.0.0.3     25
          0.0.0.0        128.0.0.0       10.22.29.1       10.22.29.3     30
         10.0.0.0    255.255.255.0         On-link          10.0.0.3    281
         10.0.0.1  255.255.255.255         10.0.0.1         10.0.0.3     25
         10.0.0.3  255.255.255.255         On-link          10.0.0.3    281
       10.0.0.255  255.255.255.255         On-link          10.0.0.3    281
       10.22.29.0    255.255.255.0         On-link        10.22.29.3    286
       10.22.29.3  255.255.255.255         On-link        10.22.29.3    286
     10.22.29.255  255.255.255.255         On-link        10.22.29.3    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        128.0.0.0        128.0.0.0       10.22.29.1       10.22.29.3     30
    208.68.38.147  255.255.255.255         10.0.0.1         10.0.0.3     25
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link          10.0.0.3    281
        224.0.0.0        240.0.0.0         On-link        10.22.29.3    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link          10.0.0.3    281
  255.255.255.255  255.255.255.255         On-link        10.22.29.3    286
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  2    281 ::/0                     fe80::21d:d1ff:fe58:4d81
  1    306 ::1/128                  On-link
  2    281 2601:9:4380:796c::/64    On-link
  2    281 2601:9:4380:796c:d58a:d43b:4b3:8911/128
                                    On-link
  2    281 2601:9:4380:796c:e1d5:c30f:18b:8fb/128
                                    On-link
  8    286 fd10:2229::/64           fd10:2229::1001
  8    286 fd10:2229::1001/128      On-link
  2    281 fe80::/64                On-link
  8    286 fe80::/64                On-link
  8    286 fe80::84fb:78bf:823d:4f9d/128
                                    On-link
  2    281 fe80::e1d5:c30f:18b:8fb/128
                                    On-link
  1    306 ff00::/8                 On-link
  2    281 ff00::/8                 On-link
  8    286 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

ipconfig for Windows-TAP adapter:

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-8E-90-B3-77
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd10:2229::1001(Preferred)
   Link-local IPv6 Address . . . . . : fe80::84fb:78bf:823d:4f9d%8(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.22.29.3(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, February 2, 2015 10:14:21 PM
   Lease Expires . . . . . . . . . . : Tuesday, February 2, 2016 10:14:21 PM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 10.22.29.0
   DHCPv6 IAID . . . . . . . . . . . : 402718606
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-C6-F0-76-08-2E-5F-7B-9E-8D

   DNS Servers . . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS over Tcpip. . . . . . . . : Enabled

Something odd probably worth noting here is the lack of default gateway. Could this be the source of the problem? Why would this not be populating?

ipconfig for WLAN adapter:

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : hsd1.ca.comcast.net.
   Description . . . . . . . . . . . : Qualcomm Atheros AR9485 802.11b|g|n WiFi
Adapter
   Physical Address. . . . . . . . . : 20-16-D8-55-26-8C
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2601:9:4380:796c:e1d5:c30f:18b:8fb(Prefer
red)
   Temporary IPv6 Address. . . . . . : 2601:9:4380:796c:d58a:d43b:4b3:8911(Prefe
rred)
   Link-local IPv6 Address . . . . . : fe80::e1d5:c30f:18b:8fb%2(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.0.3(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, February 2, 2015 4:39:05 PM
   Lease Expires . . . . . . . . . . : Monday, February 9, 2015 4:39:05 PM
   Default Gateway . . . . . . . . . : fe80::21d:d1ff:fe58:4d81%2
                                       10.0.0.1
   DHCP Server . . . . . . . . . . . : 10.0.0.1
   DHCPv6 IAID . . . . . . . . . . . : 220206808
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-C6-F0-76-08-2E-5F-7B-9E-8D

   DNS Servers . . . . . . . . . . . : 2001:558:feed::1
                                       2001:558:feed::2
                                       75.75.75.75
                                       75.75.76.76
   NetBIOS over Tcpip. . . . . . . . : Enabled

Traffic

none577 wroteI assure you it does work (at least from the successful clients)

so what is wrong with the unsuccessful clients .. is it OpenVPN or something else ?

What versions of openvpn are your server & clients ?

none577

Well, IPv6 is still getting resovled via the Windows client's WLAN interface (and therefore the actual LAN gateway rather than the VPN gateway) for some reason. In fact, all IPv6 traffic is defaulting out that way despite my 'redirect-gateway def1' entry. I mean, it appears that it should be working when looking at the routes (if I understand them correctly), but it doesn't. As as example, 'tracert google.com' on the Windows client exits out the WLAN interface rather than tunneling through the VPN. However, a tracrt on a non-IPv6-enabled site such as example.com does go through the VPN.

Server: 2.3.2 (Ubuntu 14.04)
Defective client: 2.3.6
Linux laptop: 2.3.2 (works)
Windows virtual machine on Ubuntu 14.04 host: 2.3.6 (works as stated above)

However, my laptop (and ergo my VM) are not IPv6-enabled so I can't determine whether this is purely a Windows/IPv6 combination issue or only IPv6.

none577

I figured it out! Initially, I was looking to disable IPv6 on the client machine, but I figured that wasn't the best option. So, I did some looking and came across this StackExchange article that describes IP precedence policies in Windows. By running the commands:

netsh interface ipv6 add prefixpolicy 2601:9:4380::/80 1 6 (The WLAN adapter's IP address)
netsh interface ipv6 add prefixpolicy fd10:2229::/96 10 7 (The VPN IPv6 address)

I was able to get the would-be IPv6 connections routed through the VPN. So, looks like it was a Windows-specific problem after all. This means that somehow I'm going to have to script it into the Windows config file. Do you happen to know if linking a .bat file within the ovpn file via an 'up' directive will work?

Traffic

none577 wroteI figured it out!

Excellent !

And thanks for sharing 8-)

For what it is worth, have you considered this:
https://forums.openvpn.net/topic16990.html

+v6 :mrgreen:

none577

Well, while I wasn't able to repeat my success after a reboot at least I know what to tinker with. I should be able to use a batch file to run these commands via an up or pre-up command.