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

    PSK(shared key) and PKI, forcing trafic with push setting - sit-to-sit

    Scheduled Pinned Locked Moved OpenVPN
    13 Posts 2 Posters 7.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.
    • GruensFroeschliG
      GruensFroeschli
      last edited by

      You should read this thread:
      http://forum.pfsense.org/index.php/topic,6056.0.html

      Yes you need to use a PKI to be able to use pushes.
      This includes the "redirect-gateway def1".

      But you dont need a PKI to redirect all traffic over your tunnel.

      If you read up on http://openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html
      you will find:

      –redirect-gateway [local] [def1]
          (Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.

      This option performs three steps:

      (1) Create a static route for the –remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

      (2) Delete the default gateway route.

      (3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

      When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

      Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

      Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

      Using the def1 flag is highly recommended, and is currently planned to become the default by OpenVPN 2.1.

      To solve this with a shared key setup you basically add three route entries to the tunnel config.
      a /32 entry for the remote end of the tunnel
      and 0.0.0.0/1 and 128.0.0.0/1 for the other side of the tunnel.

      –route network/IP [netmask] [gateway] [metric]
          Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.

      This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.

      netmask default – 255.255.255.255

      gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.

      The default can be specified by leaving an option blank or setting it to "default".

      The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:

      vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

      net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).

      remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode.

      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
      • M
        mj0ne
        last edited by

        @GruensFroeschli:

        You should read this thread:
        http://forum.pfsense.org/index.php/topic,6056.0.html

        Yes you need to use a PKI to be able to use pushes.
        This includes the "redirect-gateway def1".

        But you dont need a PKI to redirect all traffic over your tunnel.

        If you read up on http://openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html
        you will find:

        –redirect-gateway [local] [def1]
            (Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.

        This option performs three steps:

        (1) Create a static route for the –remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

        (2) Delete the default gateway route.

        (3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

        When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

        Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

        Add the def1 flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

        Using the def1 flag is highly recommended, and is currently planned to become the default by OpenVPN 2.1.

        To solve this with a shared key setup you basically add three route entries to the tunnel config.
        a /32 entry for the remote end of the tunnel
        and 0.0.0.0/1 and 128.0.0.0/1 for the other side of the tunnel.

        –route network/IP [netmask] [gateway] [metric]
            Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.

        This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.

        netmask default – 255.255.255.255

        gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.

        The default can be specified by leaving an option blank or setting it to "default".

        The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:

        vpn_gateway -- The remote VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

        net_gateway -- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).

        remote_host -- The --remote address if OpenVPN is being run in client mode, and is undefined in server mode.

        I'm sorry, but i don't get it. Im using "10.0.1.0/24" in the "Remote network" field on the client, which is the LAN on the master pfsense machine. I've then added a custom route in the custom field "route 10.0.3.0 255.255.255.0" for the other off-sites networks so that they can talk.

        I've tested to add "route 0.0.0.0 128.0.0.0;route 128.0.0.0 128.0.0.0" in the custom field of both to server and clients, but no luck.

        I understand that you can't use the –redirect-gateway option that you normaly pushes with PKI, so you have to add the routes "manualy" in the openvpn config.

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

          You dont add route entries on both sides.

          Think of it as if you would edit the routing table manually.
          –> You only do it on the client side if you want to redirect all traffic on the client side.

          x.x.x.x is the public remote end of your tunnel.
          y.y.y.y is your WAN gateway
          z.z.z.z is the other side of the VPN-tunnel.

          route x.x.x.x 255.255.255.255 y.y.y.y
          route 0.0.0.0 128.0.0.0 z.z.z.z
          route 128.0.0.0 128.0.0.0 z.z.z.z

          But really you could have read that out of the man-page i copied for you.

          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
          • M
            mj0ne
            last edited by

            @GruensFroeschli:

            You dont add route entries on both sides.

            Think of it as if you would edit the routing table manually.
            –> You only do it on the client side if you want to redirect all traffic on the client side.

            x.x.x.x is the public remote end of your tunnel.
            y.y.y.y is your WAN gateway
            z.z.z.z is the other side of the VPN-tunnel.

            route x.x.x.x 255.255.255.255 y.y.y.y
            route 0.0.0.0 128.0.0.0 z.z.z.z
            route 128.0.0.0 128.0.0.0 z.z.z.z

            But really you could have read that out of the man-page i copied for you.

            Ok, ive tried everything now… Im stuck in an evil thought-loop. I must misunderstand you in some of the networks. I run the test environment in vmware fusion.

            writepid /var/run/openvpn_server0.pid
            #user nobody
            #group nobody
            daemon
            keepalive 10 60
            ping-timer-rem
            persist-tun
            persist-key
            dev tun
            proto tcp-server
            cipher BF-CBC
            up /etc/rc.filter_configure
            down /etc/rc.filter_configure
            ifconfig 10.0.8.1 10.0.8.2
            lport 1194
            route 10.0.2.0 255.255.255.0
            secret /var/etc/openvpn_server0.secret
            float

            This is my openvpn_server0.conf file.

            writepid /var/run/openvpn_client0.pid
            #user nobody
            #group nobody
            daemon
            keepalive 10 60
            ping-timer-rem
            persist-tun
            persist-key
            dev tun
            proto tcp-client
            cipher BF-CBC
            up /etc/rc.filter_configure
            down /etc/rc.filter_configure
            remote 192.168.0.251 1194
            lport 1194
            ifconfig 10.0.2.2 10.0.2.1
            route 10.0.1.0 255.255.255.0
            secret /var/etc/openvpn_client0.secret
            route 10.0.1.0 255.255.255.255 192.168.0.1
            route 0.0.0.0 128.0.0.0 10.0.2.1
            route 128.0.0.0 128.0.0.0 10.0.2.1

            And this is my client. Both the client and the server are connected by "bridge-technology" to the office test network that uses 192.168.0.0/24, and 192.168.0.1 is the default gateway for both.

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

              Can you draw a diagram of what IP-range is where?
              I'm a bit confused.

              Mostly about this part:
              server: ifconfig 10.0.8.1 10.0.8.2
              client: ifconfig 10.0.2.2 10.0.2.1

              How are the server and the client supposed to communicate with each other if they dont have a common "transfer-subnet"?

              what is the 10.0.1.0 subnet? where is 192.168.0.1? should 10.0.2.x be your transfer-subnet?

              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
              • M
                mj0ne
                last edited by

                @GruensFroeschli:

                Can you draw a diagram of what IP-range is where?
                I'm a bit confused.

                Mostly about this part:
                server: ifconfig 10.0.8.1 10.0.8.2
                client: ifconfig 10.0.2.2 10.0.2.1

                How are the server and the client supposed to communicate with each other if they dont have a common "transfer-subnet"?

                what is the 10.0.1.0 subnet? where is 192.168.0.1? should 10.0.2.x be your transfer-subnet?

                192.168.0.0/24 = WAN for both server and client, thus 192.168.0.1 is both their default gateway.
                10.0.8.0/24 = "Address pool" setting in openvpn
                10.0.1.0/24 = server LAN
                10.0.2.0/24 = client LAN

                thanks alot for your help!

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

                  Ok if your two WAN's are in the same subnet you can leave the first route out.

                  But you seem to have missconfigured something because
                  server: ifconfig 10.0.8.1 10.0.8.2
                  client: ifconfig 10.0.2.2 10.0.2.1
                  is inconsistant.

                  Check your client config so that the line in question will look like ifconfig 10.0.8.2 10.0.8.1

                  It should just work if you add the two lines

                  route 0.0.0.0 128.0.0.0
                  route 128.0.0.0 128.0.0.0

                  to your client config.

                  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
                  • M
                    mj0ne
                    last edited by

                    Ok, ive change the client config to be consistant as you told me.

                    server config is the same, and my client now look like this:

                    writepid /var/run/openvpn_client0.pid
                    #user nobody
                    #group nobody
                    daemon
                    keepalive 10 60
                    ping-timer-rem
                    persist-tun
                    persist-key
                    dev tun
                    proto tcp-client
                    cipher BF-CBC
                    up /etc/rc.filter_configure
                    down /etc/rc.filter_configure
                    remote 192.168.0.251 1194
                    lport 1194
                    ifconfig 10.0.8.2 10.0.8.1
                    route 10.0.1.0 255.255.255.0
                    secret /var/etc/openvpn_client0.secret
                    route 0.0.0.0 128.0.0.0
                    route 128.0.0.0 128.0.0.0

                    I've changed the "Interface IP" field on the clients openvpn options and got the result you asked for. I can successfully ping from LAN->LAN thru the tunnel as befor. I've gotten new routes in the diag_routes.php page.

                    ![](http://timedirective.se/ss/Picture 8.png)

                    However, running a tracert the trafic stops at 10.0.8.1

                    note: the 172.16.17.0/24 subnet is vmware network.

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

                      Did you on the server end also create an AoN entry that NAT's your remote end?

                      http://forum.pfsense.org/index.php/topic,7001.0.html

                      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
                      • M
                        mj0ne
                        last edited by

                        Thanks alot for the help! Got it working! You are my hero! :)

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

                          Glad to hear it works :)

                          I assume this is a testnetwork.
                          So your two WAN's are in the same subnet.

                          If you move this into production you will have to add a static route for the WAN of the server.
                          Something like

                          route x.x.x.x 255.255.255.255 y.y.y.y

                          with x.x.x.x being the WAN of your server and y.y.y.y the gateway of your client.
                          Otherwise your client does not know how to send the VPN packets to the server after the tunnel is up.

                          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
                          • M
                            mj0ne
                            last edited by

                            @GruensFroeschli:

                            Glad to hear it works :)

                            I assume this is a testnetwork.
                            So your two WAN's are in the same subnet.

                            If you move this into production you will have to add a static route for the WAN of the server.
                            Something like

                            route x.x.x.x 255.255.255.255 y.y.y.y

                            with x.x.x.x being the WAN of your server and y.y.y.y the gateway of your client.
                            Otherwise your client does not know how to send the VPN packets to the server after the tunnel is up.

                            I'll be moving to production within a month. Thanks alot again! :)

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