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

    How to use PKI to setup site to site openvpn?

    Scheduled Pinned Locked Moved OpenVPN
    8 Posts 2 Posters 4.6k 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
      jasonwan
      last edited by

      I have setup 2 pfsense(pfSense-1.2-RC3) on the vmware network,the network structure is shown below:

      (Lan1)xpclient1–->pfsense1(server)--------------pfsense2(client)<----xpclient2(Lan2)

      xpclient1(192.168.145.140 255.255.255.0 gateway 192.168.145.2)
      pfsense1(Lan:192.168.145.2 255.255.255.0 Wan:172.30.20.14 255.255.0.0)

      pfsense2(Wan:172.30.20.9 255.255.0.0 Lan:192.168.75.2 255.255.255.0)
      xpclient2(192.168.75.140 255.255.255.0 gateway 192.168.75.2)

      server pool:192.168.2.0/24

      If I use "shared key" to setup the vpn connnection, Lan1 and Lan2 can ping each other),but if I use PKI way to setup the vpn connecton,I can't ping from each other.The openvpn on the server and client are shown below:

      On pfsense1:
      Dec 21 11:32:13 openvpn[5475]: OpenVPN 2.0.6 i386-portbld-freebsd6.2 [SSL] [LZO] built on Sep 13 2007
      Dec 21 11:32:13 openvpn[5475]: WARNING: file '/var/etc/openvpn_server1.key' is group or others accessible
      Dec 21 11:32:13 openvpn[5475]: gw 172.30.55.55
      Dec 21 11:32:13 openvpn[5475]: TUN/TAP device /dev/tun0 opened
      Dec 21 11:32:13 openvpn[5475]: /sbin/ifconfig tun0 192.168.2.1 192.168.2.2 mtu 1500 netmask 255.255.255.255 up
      Dec 21 11:32:13 openvpn[5475]: /etc/rc.filter_configure tun0 1500 1542 192.168.2.1 192.168.2.2 init
      Dec 21 11:32:14 openvpn[5490]: UDPv4 link local (bound): [undef]:1193
      Dec 21 11:32:14 openvpn[5490]: UDPv4 link remote: [undef]
      Dec 21 11:32:14 openvpn[5490]: Initialization Sequence Completed
      Dec 21 11:35:09 openvpn[5490]: 172.30.20.9:1194 Re-using SSL/TLS context
      Dec 21 11:35:09 openvpn[5490]: 172.30.20.9:1194 LZO compression initialized
      Dec 21 11:35:10 openvpn[5490]: 172.30.20.9:1194 [VPNsite] Peer Connection Initiated with 172.30.20.9:1194

      On pfsense2:
      Dec 21 11:35:09 openvpn[8855]: OpenVPN 2.0.6 i386-portbld-freebsd6.2 [SSL] [LZO] built on Sep 13 2007
      Dec 21 11:35:09 openvpn[8855]: WARNING: using –pull/--client and --ifconfig together is probably not what you want
      Dec 21 11:35:09 openvpn[8855]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
      Dec 21 11:35:09 openvpn[8855]: WARNING: file '/var/etc/openvpn_client0.key' is group or others accessible
      Dec 21 11:35:09 openvpn[8855]: LZO compression initialized
      Dec 21 11:35:09 openvpn[8856]: UDPv4 link local (bound): [undef]:1194
      Dec 21 11:35:09 openvpn[8856]: UDPv4 link remote: 172.30.20.14:1193
      Dec 21 11:35:09 openvpn[8856]: [pfsense.shg.iuniverse.com] Peer Connection Initiated with 172.30.20.14:1193
      Dec 21 11:35:10 openvpn[8856]: gw 172.30.55.55
      Dec 21 11:35:10 openvpn[8856]: TUN/TAP device /dev/tun0 opened
      Dec 21 11:35:10 openvpn[8856]: /sbin/ifconfig tun0 192.168.2.6 192.168.2.5 mtu 1500 netmask 255.255.255.255 up
      Dec 21 11:35:10 openvpn[8856]: /etc/rc.filter_configure tun0 1500 1542 192.168.2.6 192.168.2.5 init
      Dec 21 11:35:12 openvpn[8856]: Initialization Sequence Completed

      I don't know why ,can someone hlep me? Thanks very much!

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        could you provide the config files for both server and client?

        (it's in /var/etc )

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

          server:

          writepid /var/run/openvpn_server1.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 192.168.2.0 255.255.255.0
          push "route 192.168.145.0 255.255.255.0"
          lport 1193
          route 192.168.75.0 255.255.255.0
          ca /var/etc/openvpn_server1.ca
          cert /var/etc/openvpn_server1.cert
          key /var/etc/openvpn_server1.key
          dh /var/etc/openvpn_server1.dh
          comp-lzo
          persist-remote-ip
          float

          Client:

          writepid /var/run/openvpn_client0.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
          remote 172.30.20.14 1193
          client
          lport 1194
          ifconfig 192.168.2.2 192.168.2.1
          ca /var/etc/openvpn_client0.ca
          cert /var/etc/openvpn_client0.cert
          key /var/etc/openvpn_client0.key
          comp-lzo

          1 Reply Last reply Reply Quote 0
          • GruensFroeschliG
            GruensFroeschli
            last edited by

            EDIT: too tired to read right >_<

            We do what we must, because we can.

            Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

              Hi,GruensFroeschli
                  As far as I known
                push "route 192.168.145.0 255.255.255.0" is push the route to the client,witch will let the client knowing the route to the Lan1 behind pfsense1
                route 192.168.75.0 255.255.255.0  will let the pfsense1 to add this route to the lan2 behind pfsense2 automaticly with the openvpn connection estabished.

              Then I change the config of pfsense1 ,
              change “server 192.168.2.0 255.255.255.0“ to ”tls-server
              ifconfig 192.168.3.1 192.168.3.2“  ，Lans can ping each other! Any ideas?

              1 Reply Last reply Reply Quote 0
              • GruensFroeschliG
                GruensFroeschli
                last edited by

                ah sorry i mixed up your server and client config >_<

                the logoutput while getting the tunnel up looks good.
                when you use the ping tool of pfsense itself: can the two pfsense ping each other?
                might you happen to use dualwan on the server?

                We do what we must, because we can.

                Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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

                  can't ping each other,is it right?If it is right, can I make the two pfsense to ping each other?
                  And only those below can ping:
                  xpclient1 can ping xpclient2 and pfsense2's internal ip
                  xpclient2 can ping xpclient1 and pfsense1's internal ip

                  what 's the difference for my config file's changes?
                  tls-sever
                  ifconfig "192.168.2.1 192.168.2.2"

                  and
                  server 192.168.2.0 255.255.255.0

                  1 Reply Last reply Reply Quote 0
                  • GruensFroeschliG
                    GruensFroeschli
                    last edited by

                    quote from man

                    Server Mode
                    Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode is supported, and can be enabled with the –mode server option. In server mode, OpenVPN will listen on a single port for incoming client connections. All client connections will be routed through a single tun or tap interface. This mode is designed for scalability and should be able to support hundreds or even thousands of clients on sufficiently fast hardware. SSL/TLS authentication must be used in this mode.

                    --server network netmask
                        A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.

                    For example, --server 10.8.0.0 255.255.255.0 expands as follows:

                    mode server
                            tls-server

                    if dev tun:
                              ifconfig 10.8.0.1 10.8.0.2
                              ifconfig-pool 10.8.0.4 10.8.0.251
                              route 10.8.0.0 255.255.255.0
                              if client-to-client:
                                push "route 10.8.0.0 255.255.255.0"
                              else
                                push "route 10.8.0.1"

                    if dev tap:
                              ifconfig 10.8.0.1 255.255.255.0
                              ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
                              push "route-gateway 10.8.0.1"

                    TLS Mode Options:
                    TLS mode is the most powerful crypto mode of OpenVPN in both security and flexibility. TLS mode works by establishing control and data channels which are multiplexed over a single TCP/UDP port. OpenVPN initiates a TLS session over the control channel and uses it to exchange cipher and HMAC keys to protect the data channel. TLS mode uses a robust reliability layer over the UDP connection for all control channel communication, while the data channel, over which encrypted tunnel data passes, is forwarded without any mediation. The result is the best of both worlds: a fast data channel that forwards over UDP with only the overhead of encrypt, decrypt, and HMAC functions, and a control channel that provides all of the security features of TLS, including certificate-based authentication and Diffie Hellman forward secrecy.

                    To use TLS mode, each peer that runs OpenVPN should have its own local certificate/key pair ( –cert and --key ), signed by the root certificate which is specified in --ca.

                    When two OpenVPN peers connect, each presents its local certificate to the other. Each peer will then check that its partner peer presented a certificate which was signed by the master root certificate as specified in --ca.

                    If that check on both peers succeeds, then the TLS negotiation will succeed, both OpenVPN peers will exchange temporary session keys, and the tunnel will begin passing data.

                    The OpenVPN distribution contains a set of scripts for managing RSA certificates & keys, located in the easy-rsa subdirectory.

                    The easy-rsa package is also rendered in web form here: http://openvpn.net/easyrsa.html

                    --tls-server
                        Enable TLS and assume server role during TLS handshake. Note that OpenVPN is designed as a peer-to-peer application. The designation of client or server is only for the purpose of negotiating the TLS control channel.

                    so theoretically it shouldnt make a difference if you write it manually.
                    sorry i dont know why your connection is not working :(

                    We do what we must, because we can.

                    Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

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