Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved OpenVPN
    2 Posts 1 Posters 814 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mfld LAYER 8
      last edited by

      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
      tun-ipv6
      persist-tun
      persist-key
      cipher AES-128-GCM
      ncp-disable
      auth SHA512
      tls-client
      client
      resolv-retry infinite
      remote 12.34.56.78 1194 udp
      auth-user-pass
      remote-cert-tls server
      
      <ca>
      -----BEGIN CERTIFICATE-----
      XXXX
      -----END CERTIFICATE-----
      </ca>
      setenv CLIENT_CERT 0
      <tls-crypt>
      #
      # 2048 bit OpenVPN static key
      #
      -----BEGIN OpenVPN Static key V1-----
      XXXX
      -----END OpenVPN Static key V1-----
      </tls-crypt>
      
      

      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 	12.34.56.78:49146 write UDPv6: Network is unreachable (code=51)
      Aug 26 00:59:12 	openvpn 	97698 	12.34.56.78:49146 write UDPv6: Network is unreachable (code=51)
      Aug 26 00:59:09 	openvpn 	97698 	12.34.56.78:49146 write UDPv6: Network is unreachable (code=51)
      Aug 26 00:59:08 	openvpn 	97698 	12.34.56.78:49146 write UDPv6: Network is unreachable (code=51)
      Aug 26 00:59:06 	openvpn 	97698 	12.34.56.78:49146 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 ?

      1 Reply Last reply Reply Quote 0
      • M
        mfld LAYER 8
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.