Navigation

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

    OPENVPN between hardware and Virtual

    OpenVPN
    2
    7
    454
    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

                  Products

                  • Platform Overview
                  • TNSR
                  • pfSense
                  • Appliances

                  Services

                  • Training
                  • Professional Services

                  Support

                  • Subscription Plans
                  • Contact Support
                  • Product Lifecycle
                  • Documentation

                  News

                  • Media Coverage
                  • Press
                  • Events

                  Resources

                  • Blog
                  • FAQ
                  • Find a Partner
                  • Resource Library
                  • Security Information

                  Company

                  • About Us
                  • Careers
                  • Partners
                  • Contact Us
                  • Legal
                  Our Mission

                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                  Subscribe to our Newsletter

                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                  © 2021 Rubicon Communications, LLC | Privacy Policy