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

How restart OpenVPN server

Scheduled Pinned Locked Moved OpenVPN
41 Posts 14 Posters 76.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.
  • A
    akula169
    last edited by Nov 23, 2006, 12:52 AM

    @bosko:

    This is log file and error. Why does this error, if reset computer OPENVPN server start normaly.

    Nov 15 23:45:50 openvpn[5569]: Exiting
    Nov 15 23:45:50 openvpn[5569]: TCP/UDP: Socket bind failed on local address [undef]:1194: Address already in use
    Nov 15 23:45:50 openvpn[5569]: WARNING: file '/var/etc/openvpn_server0.key' is group or others accessible
    Nov 15 23:45:50 openvpn[5569]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr 6 2006

    Yeah, same problem here… openvpn is not running when I run it from the command line:

    # /usr/local/sbin/openvpn --config /var/etc/openvpn_server0.conf 
    
    Nov 22 16:03:20 router openvpn[7506]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr  6 2006
    Nov 22 16:03:20 router openvpn[7506]: WARNING: file '/var/etc/openvpn_server0.secret' is group or others accessible
    Nov 22 16:03:20 router openvpn[7506]: TCP/UDP: Socket bind failed on local address [undef]:1194: Address already in use
    Nov 22 16:03:20 router openvpn[7506]: Exiting
    

    I can't seem to find what is using 1194 when openvpn is not running.

    1 Reply Last reply Reply Quote 0
    • S
      sullrich
      last edited by Nov 24, 2006, 1:12 AM

      From a shell issue a sockstat command to see what processes are listening on what ports.

      1 Reply Last reply Reply Quote 0
      • B
        Bredys
        last edited by Nov 24, 2006, 1:37 PM Nov 24, 2006, 1:28 PM

        @sullrich:

        From a shell issue a sockstat command to see what processes are listening on what ports.

        *root     check_relo 326   11 udp4   :1194                :

        so something is wrong with check reload status… when i kill this process everything works fine!

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by Nov 24, 2006, 6:47 PM

          Eh, this doesn't make any sense.  check_reload_status doesn't even open a socket.

          1 Reply Last reply Reply Quote 0
          • A
            akula169
            last edited by Nov 24, 2006, 10:58 PM

            @sullrich:

            From a shell issue a sockstat command to see what processes are listening on what ports.

            Yeah, I've got another whole mess attached apparently:

            # sockstat | grep 1194
            root     sleep      3078  10 udp4   *:1194                *:*
            root     sh         1463  10 udp4   *:1194                *:*
            _dhcp    dhclient   1306  10 udp4   *:1194                *:*
            root     dhclient   1259  10 udp4   *:1194                *:*
            root     check_relo 659   10 udp4   *:1194                *:*
            
            1 Reply Last reply Reply Quote 0
            • B
              Bredys
              last edited by Nov 25, 2006, 9:21 AM

              sockstat | grep 1194

              root    check_relo 405  11 udp4  *:1194                :

              i try this many times… but when i try change openvpn settings, check_reload_status block port 1194. When i kill it everything work fine and i can change openvpn settings without any problem until next restart...
              After restart, openvpn run ok until i try change some options...

              1 Reply Last reply Reply Quote 0
              • D
                dairaen
                last edited by Nov 26, 2006, 11:47 AM Nov 26, 2006, 11:45 AM

                cheers,

                verified this problem on all my embedded systems and 2 firewalls
                with strong i386 hardware.

                kind regards
                dairaen

                1 Reply Last reply Reply Quote 0
                • S
                  sullrich
                  last edited by Nov 26, 2006, 5:42 PM

                  Please upgrade to http://www.pfsense.com/~sullrich/1.0.1-SNAPSHOT-11-25-2006/ and see if the problem persists.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dairaen
                    last edited by Nov 27, 2006, 6:20 PM

                    cheers,

                    i am not at the office right now, so i can't test the
                    snapshot bevore next week; i will report if it fixes the bug.

                    kind regards
                    dairaen

                    1 Reply Last reply Reply Quote 0
                    • B
                      Bredys
                      last edited by Nov 28, 2006, 1:04 PM

                      @sullrich:

                      Please upgrade to http://www.pfsense.com/~sullrich/1.0.1-SNAPSHOT-11-25-2006/ and see if the problem persists.

                      Sorry but no change for me :(

                      sockstat | grep 1194

                      root    check_relo 387  11 udp4  *:1194                :

                      Nov 28 14:14:45 openvpn[1558]: Exiting
                      Nov 28 14:14:45 openvpn[1558]: TCP/UDP: Socket bind failed on local address [undef]:1194: Address already in use
                      Nov 28 14:14:45 openvpn[1558]: Control Channel Authentication: using '/etc/tls_auth.key' as a OpenVPN static key file
                      Nov 28 14:14:45 openvpn[1558]: WARNING: file '/etc/tls_auth.key' is group or others accessible
                      Nov 28 14:14:45 openvpn[1558]: WARNING: file '/var/etc/openvpn_server0.key' is group or others accessible
                      Nov 28 14:14:45 openvpn[1558]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr 6 2006
                      Nov 28 14:14:44 openvpn[381]: SIGTERM[hard,] received, process exiting
                      Nov 28 14:14:41 openvpn[381]: /etc/rc.filter_configure tun0 1500 1542 192.168.50.1 192.168.50.2 init
                      Nov 28 14:14:41 openvpn[381]: event_wait : Interrupted system call (code=4)
                      ^^^^ After save openVPN config without any changes ^^^^

                      Nov 28 14:13:04 openvpn[381]: Need IPv6 code in mroute_extract_addr_from_packet
                      Nov 28 14:13:04 openvpn[381]: Initialization Sequence Completed
                      Nov 28 14:13:04 openvpn[381]: UDPv4 link remote: [undef]
                      Nov 28 14:13:04 openvpn[381]: UDPv4 link local (bound): [undef]:1194
                      Nov 28 14:13:01 openvpn[302]: /etc/rc.filter_configure tun0 1500 1542 192.168.50.1 192.168.50.2 init
                      Nov 28 14:13:01 openvpn[302]: /sbin/ifconfig tun0 192.168.50.1 192.168.50.2 mtu 1500 netmask 255.255.255.255 up
                      Nov 28 14:13:01 openvpn[302]: TUN/TAP device /dev/tun0 opened
                      Nov 28 14:13:01 openvpn[302]: gw 85.70.189.50
                      Nov 28 14:13:01 openvpn[302]: Control Channel Authentication: using '/etc/tls_auth.key' as a OpenVPN static key file
                      Nov 28 14:13:01 openvpn[302]: WARNING: file '/etc/tls_auth.key' is group or others accessible
                      Nov 28 14:13:01 openvpn[302]: WARNING: file '/var/etc/openvpn_server0.key' is group or others accessible
                      Nov 28 14:13:01 openvpn[302]: OpenVPN 2.0.6 i386-portbld-freebsd6.1 [SSL] [LZO] built on Apr 6 2006
                      ^^^^ Normal RESTART ^^^^

                      1 Reply Last reply Reply Quote 0
                      • S
                        sullrich
                        last edited by Nov 28, 2006, 4:50 PM

                        At this point I am at a loss.  Will have to discuss it with the other devs.  We are all really confused on this one.

                        1 Reply Last reply Reply Quote 0
                        • T
                          tpepels
                          last edited by Nov 29, 2006, 8:40 PM

                          Same problem on my box ???.

                          root    lighttpd  1785  10 tcp4  *:1194                :
                          root    check_relo 339  10 tcp4  *:1194                :

                          Hope you find the problem soon, good luck anyway!

                          1 Reply Last reply Reply Quote 0
                          • B
                            Bredys
                            last edited by Jan 4, 2007, 2:49 PM

                            Still nothing new about this problem ? I try every snapshot but without any progress :(

                            1 Reply Last reply Reply Quote 0
                            • S
                              Selective
                              last edited by Jan 5, 2007, 12:16 PM

                              The only thing you can do is to make your changes and save, click the disable box to disable tunnel and then restart pf, and when its up again, click box to enable tunnel again.

                              1 Reply Last reply Reply Quote 0
                              • T
                                trendchiller
                                last edited by Jan 5, 2007, 10:03 PM

                                Same problem here and at a friends system and at work, too… even switching to another port did not work (only for one day - using 1195 now) and the system at work... still no changes  :'(

                                1 Reply Last reply Reply Quote 0
                                • T
                                  thinair
                                  last edited by Jan 8, 2007, 4:50 AM

                                  I have the same issue (and have had for a while now), the OpenVPN server tells me whatever port number I'm using is already in use.  I've tried with the latest snapshot (Jan 7/06), same issue.

                                  Nelson Papel

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sullrich
                                    last edited by Jan 8, 2007, 4:51 AM

                                    Known issue. It's covered in 3-4 other threads but there is no solution as of yet.

                                    1 Reply Last reply Reply Quote 0
                                    • W
                                      wdbacker
                                      last edited by Jan 8, 2007, 4:37 PM

                                      I'm having the same problem with my server in UDP mode. TCP mode works perfectly for me. Looking at the listening server processes with "sockstat -l" reveals:

                                      _dhcp    dhclient  794  10 udp4  *:1194                :
                                      root    dhclient  697  10 udp4  *:1194                :

                                      Apparently, the dhclient process is listening on UDP port 1194 …  ???

                                      FYI, my box is connected at the WAN side through DHCP to my ISP. In the OpenVPN server, I enabled dynamic dns clients.

                                      1 Reply Last reply Reply Quote 0
                                      • S
                                        sullrich
                                        last edited by Jan 8, 2007, 6:13 PM

                                        There is some kind of bug where processes are inheriting other socket descriptors.

                                        1 Reply Last reply Reply Quote 0
                                        • W
                                          wdbacker
                                          last edited by Jan 13, 2007, 8:34 AM

                                          Thanks for the information Scott!

                                          I did some more testing and I saw the same problem now with the OpenVPN server in TCP mode. Hence I think it doesn't matter if the connection is through TCP or UDP, the same problem shows up. Rebooting solves the problem. The problem also seems to happen at random.

                                          If there is anything I can do to help you finding the problem (socket descriptors being reused?), I'll be happy to do more testing!

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