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

PfSense OpenVPN client to CentOS 6.5 OpenVPN server

Scheduled Pinned Locked Moved OpenVPN
15 Posts 3 Posters 1.5k 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
    cologuy
    last edited by Apr 20, 2016, 8:32 PM

    What is the 10.0.1.6 IP that is listed as the virtual IP in the Status->OpenVPN on the client? I can ping that IP address and also ssh to it but it does not seem to be my server (will not accept my password).

    1 Reply Last reply Reply Quote 0
    • D
      divsys
      last edited by Apr 20, 2016, 8:53 PM

      I would guess that's the address being given to the pfSense client by the OpenVPN server.

      If you turn up the Verb settings for both the client and the Server to "4", you'll get a wack of logged info.
      On the server, it should show you the connection attempt by the client and the address assigned on the client (among other things).

      After you've connected the client, what does the Route table look like on pfSense?

      Have you tried ssh into 10.0.1.6 from the server (assuming ssh is turned on on your pfSense box)?

      -jfp

      1 Reply Last reply Reply Quote 0
      • C
        cologuy
        last edited by Apr 20, 2016, 9:08 PM

        Ok so 10.0.1.6 is my pfSense box. I can log in to it from the server using 10.0.1.6 so I know the packets are getting that far.

        I found this in the OpenVPN log file:

        Apr 20 12:18:34 	openvpn[85721]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
        Apr 20 12:18:34 	openvpn[85721]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 10.0.1.6 10.0.1.5 init
        Apr 20 12:18:34 	openvpn[85721]: /sbin/ifconfig ovpnc1 10.0.1.6 10.0.1.5 mtu 1500 netmask 255.255.255.255 up
        Apr 20 12:18:34 	openvpn[85721]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
        Apr 20 12:18:34 	openvpn[85721]: TUN/TAP device /dev/tun1 opened
        Apr 20 12:18:34 	openvpn[85721]: TUN/TAP device ovpnc1 exists previously, keep at program end
        Apr 20 12:18:32 	openvpn[85721]: [server] Peer Connection Initiated with [AF_INET]159.203.234.144:1194
        Apr 20 12:18:30 	openvpn[85721]: UDPv4 link remote: [AF_INET]159.203.234.144:1194
        Apr 20 12:18:30 	openvpn[85721]: UDPv4 link local (bound): [AF_INET]66.76.176.130
        Apr 20 12:18:30 	openvpn[85562]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
        Apr 20 12:18:30 	openvpn[85562]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
        Apr 20 12:18:30 	openvpn[85562]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
        Apr 20 12:18:29 	openvpn[92630]: SIGTERM[hard,] received, process exiting
        Apr 20 12:18:29 	openvpn[92630]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1558 10.0.1.6 10.0.1.5 init
        Apr 20 12:18:29 	openvpn[92630]: event_wait : Interrupted system call (code=4)
        Apr 20 12:15:32 	openvpn[92630]: Initialization Sequence Completed
        

        Looks like the route add command is failing.

        I'll turn Verb higher and check it again and also look at the route table.

        1 Reply Last reply Reply Quote 0
        • C
          cologuy
          last edited by Apr 20, 2016, 9:13 PM

          Here is the routing table on the client:

          default 	aaa.aaa.aaa.1 	UGS 	0 	519132 	1500 	sk0 	 
          10.0.0.0/24 	link#7 	U 	0 	1 	1500 	sk2 	 
          10.0.0.1 	link#7 	UHS 	0 	0 	16384 	lo0 	 
          10.0.1.1/32 	10.0.1.5 	UGS 	0 	140 	1500 	ovpnc1 	 
          10.0.1.5 	link#14 	UH 	0 	0 	1500 	ovpnc1 	 
          10.0.1.6 	link#14 	UHS 	0 	3 	16384 	lo0 	 
          aaa.aaa.aaa.0/24 	link#5 	U 	0 	15773411 	1500 	sk0 	 
          aaa.aaa.aaa.aaa 	link#5 	UHS 	0 	0 	16384 	lo0 	 
          127.0.0.1 	link#12 	UH 	0 	211103 	16384 	lo0 	 
          192.168.0.0/24 	link#6 	U 	0 	230154043 	1500 	sk1 	 
          192.168.0.1 	link#6 	UHS 	0 	0 	16384 	lo0 	 
          192.168.21.0/24 	link#4 	U 	0 	0 	1500 	msk3 	 
          192.168.21.254 	link#4 	UHS 	0 	0 	16384 	lo0 	 
          192.168.201.0/24 	link#1 	U 	0 	0 	1500 	msk0 	 
          192.168.201.2 	link#1 	UHS 	0 	0 	16384 	lo0 	 
          
          

          aaa.aaa.aaa.aaa is my WAN ip on the client.  192.168.0.0, 192.168.201.0, 192.168.21.0 and 10.0.0.0 are my local networks.

          1 Reply Last reply Reply Quote 0
          • K
            kpa
            last edited by Apr 20, 2016, 9:17 PM

            The 10.0.1.6 address comes from the NET30 topology if I remember it correctly, nothing to worry about. The remote network SHOULD NOT be 10.0.1.0/24 because that is the "transfer network" where the addresses for the tun* devices are assigned for both ends of the tunnel. What should be in remote network field is the LAN address space at the remote end if applicable, this setting will cause the client to add a route to that network over the VPN tunnel.

            1 Reply Last reply Reply Quote 0
            • C
              cologuy
              last edited by Apr 20, 2016, 9:28 PM

              The server end has a WAN IP and the tun0 10.0.1.x IP's there are no other networks at that end. So should "Remote Networks" be blank?

              I had this at the server end and I think it was causing the route add command to fail:

              push "route 192.168.0.0 255.255.255.0"

              This is after I removed it and verb set to 6:

              Apr 20 16:18:39 	openvpn[35005]: /sbin/route add -net 10.0.1.1 10.0.1.5 255.255.255.255
              Apr 20 16:18:39 	openvpn[35005]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 10.0.1.6 10.0.1.5 init
              Apr 20 16:18:39 	openvpn[35005]: /sbin/ifconfig ovpnc1 10.0.1.6 10.0.1.5 mtu 1500 netmask 255.255.255.255 up
              Apr 20 16:18:39 	openvpn[35005]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
              Apr 20 16:18:39 	openvpn[35005]: TUN/TAP device /dev/tun1 opened
              Apr 20 16:18:39 	openvpn[35005]: TUN/TAP device ovpnc1 exists previously, keep at program end
              Apr 20 16:18:39 	openvpn[35005]: ROUTE_GATEWAY aaa.aaa.aaa.1
              Apr 20 16:18:39 	openvpn[35005]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
              Apr 20 16:18:39 	openvpn[35005]: OPTIONS IMPORT: route options modified
              Apr 20 16:18:39 	openvpn[35005]: OPTIONS IMPORT: --ifconfig/up options modified
              Apr 20 16:18:39 	openvpn[35005]: OPTIONS IMPORT: timers and/or timeouts modified
              Apr 20 16:18:39 	openvpn[35005]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.0.1.1,ping 10,ping-restart 120,ifconfig 10.0.1.6 10.0.1.5'
              

              Still no change in pings or access

              1 Reply Last reply Reply Quote 0
              • K
                kpa
                last edited by Apr 20, 2016, 9:30 PM

                Yes, leave the remote network blank if there's no LAN network at the server's end.

                1 Reply Last reply Reply Quote 0
                • C
                  cologuy
                  last edited by Apr 20, 2016, 9:39 PM

                  Do i need a route at the server end to the 192.168.0.0 network via the 10.0.1.0 tunnel?

                  1 Reply Last reply Reply Quote 0
                  • K
                    kpa
                    last edited by Apr 20, 2016, 9:52 PM

                    Does the server end need to have access to the 192.168.0.0/24 network? I mean as an initiator of connections to any services on 192.168.0.0/24? If not I would use NAT on the tunnel interface to hide the local network completely and you wouldn't need to set up a route back at the server.

                    1 Reply Last reply Reply Quote 0
                    • C
                      cologuy
                      last edited by Apr 21, 2016, 4:18 PM

                      No the server does not need to initiate any connections.

                      Not sure what you mean by using NAT on the tunnel interface. Can you explain that in a little more detail?

                      1 Reply Last reply Reply Quote 0
                      • K
                        kpa
                        last edited by Apr 22, 2016, 11:56 AM

                        It's been a while since I've actually run an OpenVPN server or client but roughly speaking:

                        • Assign the tun(4) interface used by the OpenVPN client as an OPT interface at the Interfaces->(assign) menu.

                        • Create a new outbound NAT rule at Firewall->NAT, set interface in the rule to the newly created OPT interface, leave everything else at defaults.

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