After hours / days of operation client tunnels die, server log shows write UDPv6: Network is unreachable (code=51)

  • I have pfSense 2.4.5-p1 running an OpenVPN Server that pushes IPv4 and IPv6.
    Clients policy-route IPv4 and IPv6 through the server.

    Clients natively only have IPv4 thus connect to the server over IPv4.

    Clients are a mix of pfSense and ASUS routers.

    The OpenVPN config exporter generates:

    dev tun
    cipher AES-128-GCM
    auth SHA512
    resolv-retry infinite
    remote 1194 udp
    remote-cert-tls server
    -----END CERTIFICATE-----
    setenv CLIENT_CERT 0
    # 2048 bit OpenVPN static key
    -----BEGIN OpenVPN Static key V1-----
    -----END OpenVPN Static key V1-----

    user/pass authentication is done via radius.

    My issue is that clients connect and everything works fine for a while but at some random point in time that can be as long as 20, 30, 48 hours after initial connection, the client will die. Restarting OpenVPN on the client or rebooting the client device will not re-establish the tunnel.

    On the pfSense server I see this in the OpenVPN logs:

    Aug 26 00:59:13 	openvpn 	97698 write UDPv6: Network is unreachable (code=51)
    Aug 26 00:59:12 	openvpn 	97698 write UDPv6: Network is unreachable (code=51)
    Aug 26 00:59:09 	openvpn 	97698 write UDPv6: Network is unreachable (code=51)
    Aug 26 00:59:08 	openvpn 	97698 write UDPv6: Network is unreachable (code=51)
    Aug 26 00:59:06 	openvpn 	97698 write UDPv6: Network is unreachable (code=51)

    Why is it trying to "write UDPv6" to the client's IPv4 address ?

    The only way to make the affected client reconnect is to restart the OpenVPN service on the server side. Which is not ideal as it will force all clients to reconnect.

    Initially it happened on an ASUS Merlin firmware client so I did not pay much attention to it thinking once I got them to install their SG-1100 / SG-3100 this won't be an issue anymore.

    Now I notice it happens with pfSense 2.4.5-p1 clients as well so I think it is something about my OpenVPN server setup that seems to be wrong.

    I thought maybe the key renegotiation fails somehow but I have reneg-sec set to defaults (i.e. not touched) and I see in the logs that renegotiation does succeed every hour.

    Client user/pass auth comes from a Radius server. No two-factor auth involved. The radius server seems reachable at all times.

    I tried toggling "Client Settings -> Dynamic IP" to ON because some poorly conceived Google session lead me to believe that it might have something to do with it. - It doesn't :)

    I do have "Server Protocol: multihome" ticked on the server. Currently clients only have IPv4 but I wanted them to be able to connect via IPv6 too if needed. Could this be the issue ?

  • Anyone having the same issue who found this via search:

    I have been able to replicate the issue on several devices now and I was able to stop it from happening by making the server UDP4 only, not multi-home UDP4/UDP6.

    Seems like a bug to me because the server does have native IPv4 and IPv6 but the only configuration change that made this issue go away was changing the server to UDP4.

Log in to reply