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

    Power cycling and OpenVPN issues

    Scheduled Pinned Locked Moved OpenVPN
    2 Posts 2 Posters 2.3k 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
      mezza
      last edited by

      I've got a pair of OpenVPN installations (1.2RC3) on some Alix WRAPs which are working well. Good performance over an SSL site-to-site VPN etc.

      However, one of the boxes (which is by chance the site-to-site OpenVPN client) is in a remote location abroad in an environment with unreliable power. Even though the device is powered via a small UPS, there seem to be outages where the box is power cycled.

      When power is restored, the client reboots fine and DHCP and general routing service is restored, but the OpenVPN site-to-site fails?! Connections to the client box's Roadwarrior OpenVPN server work fine.

      Looking at the logs on the site-to-site server (194.XXX.XXX.123):

      Jan 28 09:16:35 s2sclient openvpn[407]: Inactivity timeout (–ping-restart), restarting
      Jan 28 09:16:35 s2sclient openvpn[407]: SIGUSR1[soft,ping-restart] received, process restarting
      Jan 28 09:16:37 s2sclient openvpn[407]: Re-using pre-shared static key
      Jan 28 09:16:37 s2sclient openvpn[407]: LZO compression initialized
      Jan 28 09:16:37 s2sclient openvpn[407]: TCP/UDP: Preserving recently used remote address: 220.XXX.XXX.234:1194
      Jan 28 09:16:37 s2sclient openvpn[407]: Preserving previous TUN/TAP instance: tuCLOG???

      And also on the site-to-site client (220.XXX.XX.234):

      Jan 28 14:53:40 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 LZO compression initialized
      Jan 28 14:53:40 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: reading acknowledgement record from packet
      Jan 28 14:53:52 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=23
      Jan 28 14:54:03 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: client->client or server->server connection attempted from 194.XXX.XXX.123:1195
      Jan 28 14:54:03 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=20
      Jan 28 14:54:12 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=24
      Jan 28 14:54:12 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=15
      Jan 28 14:54:22 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=0
      Jan 28 14:54:22 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=13
      Jan 28 14:54:32 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: unknown opcode received from 194.XXX.XXX.123:1195 op=29
      Jan 28 14:54:32 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: Unroutable control packet received from 194.XXX.XXX.123:1195 (si=3 op=P_ACK_V1)
      Jan 28 14:54:40 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
      Jan 28 14:54:40 s2sserver openvpn[374]: 194.XXX.XXX.123:1195 TLS Error: TLS handshake failed

      It seems to be that the server is trying to reuse the tun/tap instance that existed before the power cut, which clearly no longer exists on the client. What do I need to specify - and where - to ensure the site-to-site gets reestablished once power resumes?

      Thanks in advance.

      mezza

      1 Reply Last reply Reply Quote 0
      • C
        chazers18
        last edited by

        Get a bigger UPS ;D

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