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

    OpenVPN point-to-point: connection up but remote access eventually fails from LAN

    Scheduled Pinned Locked Moved OpenVPN
    1 Posts 1 Posters 270 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.
    • D
      darrenavid
      last edited by darrenavid

      Hi all-

      I'm hitting an odd issue on 2.4.5-RELEASE that seems to have crept up only in the past several months. I have a working point-to-point OpenVPN connection between two pfSense systems (System A and System B). After a few days, machines on the System A LAN are unable to access machines on the System B LAN (including pinging the gateway).

      When I check OpenVPN status on System B, i see the following set of messages once a minute (oddly, this is the case whether or not the traffic over the network is working or not):

      Jan 27 06:31:37	openvpn	53821	MANAGEMENT: CMD 'status 2'
      Jan 27 06:31:37	openvpn	53821	MANAGEMENT: Client connected from /var/etc/openvpn/server4.sock
      Jan 27 06:31:37	openvpn	27421	MANAGEMENT: Client disconnected
      Jan 27 06:31:37	openvpn	27421	MANAGEMENT: CMD 'quit'
      

      (Re: the above log entries, this post seems to indicate this is normal, my logging verbosity is set to 3 on the server.)

      The only thing that seems to fix this issue is to restart both the server and client OpenVPN connections, then all returns to working for a few more days. I can't seem to track down how it's getting into this state, or where the issue lies.

      Anecdotally, I will add that I'm streaming MP3 files over this connection using Sonos (System A) and Subsonic (System B), which seems to be when the VPN fails -- that's likely correlation but not causation.

      I just installed syslog-ng on both systems to hopefully gather more forensic data, but I thought I'd post here to see if this behavior might have some obvious places to check.

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