I am trying to set up an openvpn server and a RouterOS ovpn client, and have successfully got this working for IPv4.
I am now trying to set up openvpn to hand out an IPv6 address, and I am struggling, the openvpn side logs that an IPv6 address is offered to the RouterOS side, but the RouterOS side ignores this and configures IPv4 only.
Is there a modern, up to date howto for openvpn+ipv6 anywhere for RouterOS? Does ovpn-client support ipv6 at all?
What I have found is that the tunnel seems to be established without a problem, and IPv4 works. The IPv6 address that is sent by the openvpn server is ignored by routeros, but routeros will happily let you assign the IPv6 address to the tunnel interface, and at this point IPv6 works fine… but…
IPv6 traffic only flows when traffic is flowing from the ovpn-client to the openvpn server. If an attempt is made to ping the client from the server, you get “Address unreachable”. As soon as traffic (such as another ping) starts flowing from the client to the server, the ping from the server to the client magically starts working.
[root@257233-app1 openvpn]# ping6 2001:4800:xxxx:xxx:8000::3
PING 2001:4800:xxx:xxx:8000::3(2001:4800:1020:395:8000::3) 56 data bytes
From 2001:4800:xxxx:xxx::7a25 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:4800:xxxx:xxx::7a25 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:4800:xxxx:xxx::7a25 icmp_seq=3 Destination unreachable: Address unreachable
From 2001:4800:xxxx:xxx::7a25 icmp_seq=5 Destination unreachable: Address unreachable
From 2001:4800:xxxx:xxx::7a25 icmp_seq=6 Destination unreachable: Address unreachable
From 2001:4800:xxxx:xxx::7a25 icmp_seq=7 Destination unreachable: Address unreachable
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=8 ttl=64 time=200 ms
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=9 ttl=64 time=114 ms
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=10 ttl=64 time=114 ms
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=11 ttl=64 time=114 ms
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=12 ttl=64 time=114 ms
64 bytes from 2001:4800:xxxx:xxx:8000::3: icmp_seq=13 ttl=64 time=114 ms
Not completely true. IPv6 may not be supported “on OpenVPN level”, but if you use ethernet mode, you’re free to run any protocol over it, IPv6 included. RouterOS works fine with it (both client and server) and standard OpenVPN should too (but I personally tested only Windows OpenVPN client). Few years ago I used it for a while and it worked great.
Well, if there is anybody that can get it working - I’d sure appreciate the help. I already tried Ethernet and I couldn’t get it to work - the OVPN server rejects the connection if it is configured to tunnel IPV6 and a RouterOS device connects.
I’ve been running IPv6 on RouterOS for years .. since the 3.x pre-releases. It works perfectly on ethernet level and 6in4 tunnels can be used to bridge it over the stuff, where it doesn’t work.
I’m just missing it for the OpenVPN package.
So, 6in4 over an OpenVPN tunnel works. It’s just very unhandy for a mobile client, to establish multiple connections to get it going. Especially when IPv6 support for OpenVPN is defined and available. I did send a mail to support and was told, it’s on the road map, but it won’t happen in 6.x
It worked fine with Windows OpenVPN as client. RouterOS as client works too, but needs to add IPv6 address manually. I admit it’s not for everyone, both manual address and autoconfiguration might be problematic for some use.
I now very quickly tested Linux OpenVPN server with RouterOS client and it seems to be able to work the same way. You can’t depend on “server-ipv6” option, because RouterOS ignores it. But it’s still possible to assign address manually, either on RouterOS side only, or remove server-ipv6 and also add manual address to tap interface on server side. Again, manual addresses are not the best thing, I agree. But it could probably be worked around by using DHCPv6 server (if your OpenVPN server is not RouterOS, because its DHCPv6 server can’t provide addresses). I will try to test it later.