#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: | |
Cc: |
Description
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 13 years ago by
comment:2 Changed 13 years ago by
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
comment:3 Changed 13 years ago by
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 13 years ago by
Owner: | set to Gert Döring |
---|---|
Priority: | major → minor |
Status: | new → accepted |
comment:5 Changed 13 years ago by
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 13 years ago by
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
comment:7 Changed 12 years ago by
Milestone: | → beta 2.3 |
---|---|
Version: | 2.2-beta / 2.2-RC → openvpn-testing |
comment:8 Changed 11 years ago by
Resolution: | → invalid |
---|---|
Status: | accepted → closed |
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.
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