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

    OPENVPN between hardware and Virtual

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 2 Posters 724 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.
    • J
      Jamerson
      last edited by

      Hi guys,
      we have a openvpn site to site configured between two Pfsense
      one hardware and one virtual running on the esxi.
      between the virtual pfsense 2.4.2 and the internet there is a ISP Modem and the ports has been forwarded to the device.
      however i can't get it to work.
      the tunnel is not up at all.
      Can someone please advies how to get this fixed ?

      [Edit: I think you posted this, now removed, part on the wrong forum  ;) Steve]

      the log is as below when i restart the connection.

      [code]Nov 23 01:13:43	openvpn[58575]: UDPv4 link remote: [AF_UNSPEC]
Nov 23 01:13:43	openvpn[58575]: UDPv4 link local (bound): [AF_INET]56.77.88.990:10445
Nov 23 01:13:43	openvpn[58575]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Nov 23 01:13:43	openvpn[58575]: /usr/local/sbin/ovpn-linkup ovpns3 1500 1605 10.3.0.1 10.3.0.2 init
Nov 23 01:13:43	openvpn[58575]: /sbin/ifconfig ovpns3 10.3.0.1 10.3.0.2 mtu 1500 netmask 255.255.255.255 up
Nov 23 01:13:43	openvpn[58575]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Nov 23 01:13:43	openvpn[58575]: TUN/TAP device /dev/tun3 opened
Nov 23 01:13:43	openvpn[58575]: TUN/TAP device ovpns3 exists previously, keep at program end
Nov 23 01:13:43	openvpn[58575]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 23 01:13:43	openvpn[58228]: library versions: OpenSSL 1.0.2m 2 Nov 2017, LZO 2.10
Nov 23 01:13:43	openvpn[58228]: OpenVPN 2.4.4 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 3 2017
Nov 23 01:13:43	openvpn[58228]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Nov 23 01:13:42	openvpn[35180]: SIGTERM[hard,] received, process exiting
Nov 23 01:13:41	openvpn[35180]: /usr/local/sbin/ovpn-linkdown ovpns3 1500 1605 10.3.0.1 10.3.0.2 init
Nov 23 01:13:41	openvpn[35180]: event_wait : Interrupted system call (code=4)
Nov 23 01:13:37	openvpn[79651]: UDPv4 link remote: [AF_UNSPEC]
Nov 23 01:13:37	openvpn[79651]: UDPv4 link local (bound): [AF_INET]56.77.88.990:10449
Nov 23 01:13:37	openvpn[79651]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Nov 23 01:13:37	openvpn[79651]: /usr/local/sbin/ovpn-linkup ovpns9 1500 1605 10.9.9.1 10.9.9.2 init
Nov 23 01:13:37	openvpn[79651]: /sbin/ifconfig ovpns9 10.9.9.1 10.9.9.2 mtu 1500 netmask 255.255.255.255 up
Nov 23 01:13:37	openvpn[79651]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Nov 23 01:13:37	openvpn[79651]: TUN/TAP device /dev/tun9 opened
Nov 23 01:13:37	openvpn[79651]: TUN/TAP device ovpns9 exists previously, keep at program end
Nov 23 01:13:37	openvpn[79651]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 23 01:13:37	openvpn[79326]: library versions: OpenSSL 1.0.2m 2 Nov 2017, LZO 2.10
Nov 23 01:13:37	openvpn[79326]: OpenVPN 2.4.4 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 3 2017
Nov 23 01:13:37	openvpn[79326]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Nov 23 01:13:37	openvpn[57213]: SIGTERM[hard,] received, process exiting
Nov 23 01:13:36	openvpn[57213]: /usr/local/sbin/ovpn-linkdown ovpns9 1500 1605 10.9.9.1 10.9.9.2 init
Nov 23 01:13:36	openvpn[57213]: event_wait : Interrupted system call (code=4)[/code]

      Thank you

      1 Reply Last reply Reply Quote 0
      • V
        viragomann
        last edited by

        There seems nothing wrong in the server start-up, but what shows the client log? Can the client generally reach the server?

        1 Reply Last reply Reply Quote 0
        • J
          Jamerson
          last edited by

          Thank you for your answer,
          this the log of the client

          The ISP Router is Vigor 2760

          Nov 23 22:48:36	openvpn	11434	Re-using pre-shared static key
Nov 23 22:48:36	openvpn	11434	Preserving previous TUN/TAP instance: ovpnc2
Nov 23 22:48:36	openvpn	11434	TCP/UDP: Preserving recently used remote address: [AF_INET]SERVERIP:10449
Nov 23 22:48:36	openvpn	11434	UDPv4 link local (bound): [AF_INET]192.168.1.60:10449
Nov 23 22:48:36	openvpn	11434	UDPv4 link remote: [AF_INET]5.200.4.66:10449
Nov 23 22:49:36	openvpn	11434	Inactivity timeout (--ping-restart), restarting
Nov 23 22:49:36	openvpn	11434	SIGUSR1[soft,ping-restart] received, process restarting
Nov 23 22:54:36	openvpn	11434	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 23 22:54:36	openvpn	11434	Re-using pre-shared static key
Nov 23 22:54:36	openvpn	11434	Preserving previous TUN/TAP instance: ovpnc2
Nov 23 22:54:36	openvpn	11434	TCP/UDP: Preserving recently used remote address: [AF_INET]SERVERIP:10449
Nov 23 22:54:36	openvpn	11434	UDPv4 link local (bound): [AF_INET]192.168.1.60:10449
Nov 23 22:54:36	openvpn	11434	UDPv4 link remote: [AF_INET]SERVERIP:10449
Nov 23 22:55:36	openvpn	11434	Inactivity timeout (--ping-restart), restarting
          1 Reply Last reply Reply Quote 0
          • V
            viragomann
            last edited by

            Obviously the client can't reach the server.
            Have you opened up the port on the server pfSense?

            Since the Vigor will do NAT and you have a private WAN subnet you have the remove the check in the WAN interface settings at "Block private networks". Have you done that?

            To check if the connection packets arrive at the servers WAN interface run a packet capture on pfSense, filtering for UDP protocol and the destination port 10449.

            1 Reply Last reply Reply Quote 0
            • J
              Jamerson
              last edited by

              @viragomann:

              Obviously the client can't reach the server.
              Have you opened up the port on the server pfSense?

              Since the Vigor will do NAT and you have a private WAN subnet you have the remove the check in the WAN interface settings at "Block private networks". Have you done that?

              To check if the connection packets arrive at the servers WAN interface run a packet capture on pfSense, filtering for UDP protocol and the destination port 10449.

              Thank you for your answer,
              on the server side the port is already opend and client firewall didn't handshake the server firewall.
              Block private network is unselected
              with packet capture there is no log of the client trying to handshake the server.

              we are using a draytek 2860 and port for the vpn server is forwarded to the internal LAN IP of the Pfsense.
              is this issue with the server or client ?

              1 Reply Last reply Reply Quote 0
              • V
                viragomann
                last edited by

                Maybe it's your ISP if he blocks the packets.

                Your server log shows a second server, listening to UDP 10445. Is it accessible?
                If it is the other server should be as well.

                1 Reply Last reply Reply Quote 0
                • J
                  Jamerson
                  last edited by

                  @viragomann:

                  Maybe it's your ISP if he blocks the packets.

                  Your server log shows a second server, listening to UDP 10445. Is it accessible?
                  If it is the other server should be as well.

                  yes on both sides are the openvpn opens to listen to each others.
                  ISP is not blocking anything as it used to work untill the last update .
                  its appear the firewall is blocking the traffic to leave and i beleive is a routing issue.
                  just dont know where to start
                  thank you

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