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

Duplicate common name

Scheduled Pinned Locked Moved OpenVPN
4 Posts 1 Posters 2.8k 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.
  • C
    cdenley
    last edited by Jan 20, 2010, 9:31 PM

    Why are my users allowed to use duplicate common names? It causes the OpenVPN server to alternate between the two connections according to the log, but both clients seem to work fine. How do I enforce a certificate only being used from one client at a time? I thought this was the default, since I didn't add the duplicate-cn option anywhere.

    1 Reply Last reply Reply Quote 0
    • C
      cdenley
      last edited by Jan 20, 2010, 10:18 PM

      The OpenVPN server doesn't seem to be launched with that option set, so I don't know why I'm able to connect with duplicate common names. This is possible with UDP, right?

      
      # ps -x | grep "[o]penvpn"
        487  ??  Ss     0:22.78 openvpn --config /var/etc/openvpn_server0.conf
      # cat /var/etc/openvpn_server0.conf
      writepid /var/run/openvpn_server0.pid
      #user nobody
      #group nobody
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      dev tun
      proto udp
      cipher BF-CBC
      up /etc/rc.filter_configure
      down /etc/rc.filter_configure
      server 10.3.0.0 255.255.255.0
      client-config-dir /var/etc/openvpn_csc
      push "route 10.4.0.0 255.255.254.0"
      lport 1194
      push "dhcp-option WINS 10.4.0.2"
      ca /var/etc/openvpn_server0.ca
      cert /var/etc/openvpn_server0.cert
      key /var/etc/openvpn_server0.key
      dh /var/etc/openvpn_server0.dh
      comp-lzo
      status /var/log/openvpn-status.log
      log-append  /var/log/openvpn.log
      local 192.168.0.1
      
      
      1 Reply Last reply Reply Quote 0
      • C
        cdenley
        last edited by Jan 20, 2010, 10:29 PM

        The server seems to be doing an "inactivity timeout", restarting the client's connection every minute, alternating between the two duplicates.

        
        Wed Jan 20 16:15:42 2010 Initialization Sequence Completed
        Wed Jan 20 16:17:33 2010 [server] Inactivity timeout (--ping-restart), restarting
        Wed Jan 20 16:17:33 2010 TCP/UDP: Closing socket
        Wed Jan 20 16:17:33 2010 SIGUSR1[soft,ping-restart] received, process restarting
        Wed Jan 20 16:17:33 2010 Restart pause, 2 second(s)
        
        

        I will get this on client A one minute, then client B the next, then again on client A. If client A is connected, I would expect client B to simply fail to connect? Does it not work this way?

        1 Reply Last reply Reply Quote 0
        • C
          cdenley
          last edited by Jan 21, 2010, 2:31 PM

          I figured it out. It was the "keepalive 10 60" option which is put in the server configuration automatically by pfsense. This should really be optional! That option in server mode is equivalent to:

          
          ping 10
          ping-restart 120
          push "ping 10"
          push "ping-restart 60"
          
          

          This tells the client to restart the connection if it goes 60 seconds without a ping from the server. If client A connects, then client B connects with the same common name, client A loses their connection. However, client A doesn't realize it lost its connection until it never receives a ping from the server, which then results in client A restarting. Then the same happens to client B, then back and forth. Why would this be the default? I had to edit openvpn.inc to remove the "keepalive" option, then push "ping-exit" to the client instead of "ping-restart".

          1 Reply Last reply Reply Quote 0
          1 out of 4
          • First post
            1/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received