IPv6 neighbor solicitation not working with Windows

[Maximilian Grobecker]

I'm using OpenVPN 2.2-beta3 on Windows Vista and Windows 7.
On both systems IPv6 neighbor solicitation is not working so I can't talk to any IPv6 address over the tunnel connection.

Wireshark shows incoming and outgoing IPv6 packets and also the neighbor solicitation requests, but no answers.

With netsh I added the MAC address of the OpenVPN tunnel device on the server and now communication with IPv6 clients on the other side of the tunnel works.

Please let me know if you need additional information like config files or routing tables.

[Gert Döring]

Please show your configs.

I assume that you are using a point-to-point "dev tun" setup, and this is not yet fully implemented on Windows (since OpenVPN 2.2 does not have any support for setting up IPv6 at all yet, and Windows tap driver needs special tending to get this right).

I might be able to tell you a workaround (the way OpenVPN 2.3 handles this) but need to see your config and setup scripts to verify that my theory is right.

gert

[Maximilian Grobecker]

It's a point-to-multipoint setup, here is my server config:

server 188.xxx.xxx.xxx 255.255.252.0

dev tun
proto udp
port 1194
local 188.xxx.xxx.xxx

dev tun-vpn-tls

keepalive 10 180
ping-timer-rem

tun-mtu 1440
fragment 1400
mssfix

float

tls-server
tls-auth /etc/openvpn/keys/vpn-tunnel/ta.key 0

dh /etc/openvpn/keys/vpn-tunnel/dh1024.pem
ca /etc/openvpn/keys/vpn-tunnel/ca.crt
cert /etc/openvpn/keys/vpn-tunnel/server.crt
key /etc/openvpn/keys/vpn-tunnel/server.key

client-cert-not-required

user nobody
group nogroup

persist-key
persist-tun

status /var/log/vpn/vpn-server.log 1
verb 3
#verb 7

tun-ipv6
server-ipv6 2a02:a00:xxxx:xxxx:xxxx::/64
ifconfig-pool-persist /var/log/openvpn/ip.txt
#mute 10

script-security 2

topology subnet

username-as-common-name
client-config-dir /tmp/

#plugin /usr/lib/openvpn/openvpn-auth-pam.so login
plugin /etc/openvpn/radiusplugin.so
#plugin /root/openvpn/radiusplugin_v2.1_beta9/radiusplugin.so

And here's my client config:

client
dev tun
proto udp
tun-mtu 1440
fragment 1400
mssfix
remote xxxxxxxxxxx.de 1194
auth-user-pass
auth-retry interact
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt 
tls-auth ta.key 1
ns-cert-type server

# Debug Level
verb 3
tun-ipv6

#redirect-gateway

script-security 2

# These scripts are used for adding and deleting neighbor entries
up addneighbor.bat
down delneighbor.bat

[Gert Döring]

I was about to say "point-to-multipoint tun has no support for IPv6", but since you have server-ipv6 in your config, you're not using stock 2.2-beta3 on the server :-)

Can you show me the addneighbor.bat scripts that you use?

Most likely it's enough to make sure that the IPv6 route is pointed to a gateway address of fe80::8 - this is a magic address for which the tap.sys driver will fake a reply to the neighbor discovery packet, so windows nd will succeed and packets can flow. This is what OpenVPN "testing" currently does:

netsh interface ipv6 add route 2001:dba::/32 MyTapDevice? fe80::8

note the "fe80::8" at the end.

(The underlying problem here is that there is no neighbour discovery on real "tun" devices - so the server side cannot handle that. OTOH, windows tap is always an "ethernet" device with full nd and MAC addresses and everything, so we have to fake it... same thing for IPv4 and ARP requests)

[mgrobecker]

Sorry, didn't worked out.
I used
netsh interface ipv6 add route 2a02:a00:xxxx:xxx::/64 16 fe80::8

The only change is, that fe80::8 appears in
netsh interface ipv6 show neighbors
as "unreachable".

My addneighbor.bat executes only one command:

c:\windows\system32\netsh.exe interface ipv6 add neighbor %1 2a02:a00:xxxx:xxxx::1 00-ff-77-08-00-2f

Where 00-ff-77-08-00-2f is the MAC address of the OpenVPN server. %1 will be replaced by the device name.

[Gert Döring]

Hi,

this surprises me a bit - who is setting the ipv6 route? If you use 2.2-beta3, the "addneighbour" command needs to also set the route, not only the neighbour, because OpenVPN 2.2-beta3 does not know how to set the route.

Also, in the "netsh ... route" command that you've pasted: could you please try with the name of the TAP interface, not with the number "16"? The code in OpenVPN 2.3 does exactly this - setup the route to the named interface with a next-hop of fe80::8, and it works nicely.

If that does not work for you, you can of course stick with the "ipv6 add neighbor" statement - it does not have to be the MAC address of the OpenVPN server. Any MAC address will do - in tun mode, mac addresses are not transmitted over the OpenVPN session anyway (so neighbour discovery can never work).

gert

[Gert Döring]

I'm closing this now.

There is no formal IPv6 support in OpenVPN 2.2, while it's working, well-tested and officially supported in 2.3 (including 2.3_beta1).

It might be possible to make it work with 2.2, but that needs a bit more feedback from the original reporter - if I get no responses, I can not offer advice.

[tct]

cc