Opened 14 years ago

Closed 12 years ago

Last modified 5 years ago

#61 closed Bug / Defect (invalid)

IPv6 neighbor solicitation not working with Windows

Reported by: Maximilian Grobecker Owned by: Gert Döring
Priority: minor Milestone: beta 2.3
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


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.

Change History (9)

comment:1 Changed 14 years ago by 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.


comment:2 Changed 14 years ago by Maximilian Grobecker

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


dev tun
proto udp
port 1194

dev tun-vpn-tls

keepalive 10 180

tun-mtu 1440
fragment 1400


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


user nobody
group nogroup


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

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

script-security 2

topology subnet

client-config-dir /tmp/

#plugin /usr/lib/openvpn/ login
plugin /etc/openvpn/
#plugin /root/openvpn/radiusplugin_v2.1_beta9/

And here's my client config:

dev tun
proto udp
tun-mtu 1440
fragment 1400
remote 1194
auth-retry interact
resolv-retry infinite
ca ca.crt 
tls-auth ta.key 1
ns-cert-type server

# Debug Level
verb 3


script-security 2

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

comment:3 Changed 14 years ago by 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)

comment:4 Changed 14 years ago by Gert Döring

Owner: set to Gert Döring
Priority: majorminor
Status: newaccepted

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by Gert Döring


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


comment:7 Changed 13 years ago by David Sommerseth

Milestone: beta 2.3
Version: 2.2-beta / 2.2-RCopenvpn-testing

comment:8 Changed 12 years ago by Gert Döring

Resolution: invalid
Status: acceptedclosed

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.

comment:9 Changed 5 years ago by tct


Note: See TracTickets for help on using tickets.