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

    OpenVPN Client-to-Client routing with Preshared Key

    Scheduled Pinned Locked Moved OpenVPN
    13 Posts 3 Posters 3.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.
    • D
      doktornotor Banned
      last edited by

      https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

      1 Reply Last reply Reply Quote 0
      • M
        Mando555
        last edited by

        Thank you doktornotor for the reply however, I am already setup as outlined by that article. I'll embed the images so that it's easier to see.

        OpenVPN Client A-C

        OpenVPN Client B-C

        OpenVPN Server A-C 1of2

        OpenVPN Server A-C 2of2

        OpenVPN Server B-C 1of2

        OpenVPN Server B-C 2of2

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by

          I cannot make sense of the A-C, B-C, ACDC 1 of X stuff… There's no need for this push whatever and other advanced config on 2.2

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            That ^ - do not put anything in the Advanced box.
            The Local and Remote Network/s boxes do all the work for you.
            Make sure that what is in "IPv4 Remote Network/s" is the IP subnet(s) that are at the OTHER END of the OpenVPN link.
            e.g. at location A, the OpenVPN instance that goes to location C has IPv4 Remote Network 192.168.106.0/24

            I also do not known which client and server screen shot is at location C, B or A - you have not explained the naming convention, "Client A-C" - is that the Client that is setup on A and connects to C, or the client that is setup on C and connects to A?

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • M
              Mando555
              last edited by

              @phil.davis:

              That ^ - do not put anything in the Advanced box.
              The Local and Remote Network/s boxes do all the work for you.
              Make sure that what is in "IPv4 Remote Network/s" is the IP subnet(s) that are at the OTHER END of the OpenVPN link.
              e.g. at location A, the OpenVPN instance that goes to location C has IPv4 Remote Network 192.168.106.0/24

              I also do not known which client and server screen shot is at location C, B or A - you have not explained the naming convention, "Client A-C" - is that the Client that is setup on A and connects to C, or the client that is setup on C and connects to A?

              Thank you for the reply.

              From the first post there is 3 locations A, B, C with respective subnets shown in the OP.
              A - OpenVPN Server
              B - OpenVPN Server
              C - Client to A Server
              C - Client to B Server

              Each location has a windows server that performs DNS, DHCP, and AD. Each location's AD is it's own forest.

              The remote networks are properly configured inside the server and client. I can reach all the services provided by pfsense and windows severs but I cannot reach any other machines on the network!

              My client is going crazy cause they can't do payroll :( I tried everything I can think of I spent way too many hours on this!

              [edit]
              I don't know if it's clear but I need to be able to ping/connect to all the machines from A and B at location C.

              i.e. At Location C reach workstation 192.168.1.99 on Location B.
              i.e. At Location C reach workstation 192.168.42.90 on Location A.

              I'm on pfSense 2.1.5.

              Thank you doktornotor and phil.davis!

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                Good - you must have OpenVPN links working and reasonable firewall rules that are permitting traffic.
                My guess is that the other systems (e.g. Windows Desktop Clients) have a firewall that is stopping ping from outside their own subnet.
                Also use "tracert" from on end to the other - then you can see the hops that the data is taking and where it stops.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • M
                  Mando555
                  last edited by

                  @phil.davis:

                  Good - you must have OpenVPN links working and reasonable firewall rules that are permitting traffic.
                  My guess is that the other systems (e.g. Windows Desktop Clients) have a firewall that is stopping ping from outside their own subnet.
                  Also use "tracert" from on end to the other - then you can see the hops that the data is taking and where it stops.

                  thank you for the fast response!

                  When I tracert I would get:
                  Gateway [pfsense] -> OpenVPN Tunnel Network -> Dead

                  When i tracert the server I would get:
                  Gateway [pfsense] -> Open VPN Tunnel Network -> 192.168.1.100 [Server]

                  What if I go into pfsense under routing and add a static route for the remote subnet???

                  Firewalls are disabled and the strange thing is from Location B I can reach the terminal at Location A! So firewall I think is unlikely to be the issue.

                  Thank you again for the response it's much appreciated.

                  I have pfsense support credits and opened a ticket hopefully I hear back something soon!

                  [edit]
                  before the tunnel netowrk was 10.220.220.0/30 for example and I changed it to /24 network on both ends. I didn't know if each station at a remote location needs to be able to grab an IP from the tunnel network so I changed it. I restarted the OpenVPN services but I don't think it's necessary as it's site-to-site and pfsense will handle the routing?

                  1 Reply Last reply Reply Quote 0
                  • M
                    Mando555
                    last edited by

                    F*********!!!

                    I did some further testing. There's machines on the same subnet that can't talk to each other! I found some remote subnets that I could talk to! Sh*t I think this means OpenVPN is fine and I have gremlins elsewhere! The two devices I need to connect to are clock in stations with no firewalls which further adds to my confusion. I found one windows 7 machine that I can ping on the remote network.

                    This is from Location C pinging Location A - Win7 Machine

                    C:\Windows\system32>ping 192.168.42.111 Pinging 192.168.42.111 with 32 bytes of data: Reply from 192.168.42.111: bytes=32 time=19ms TTL=126 Reply from 192.168.42.111: bytes=32 time=18ms TTL=126 Reply from 192.168.42.111: bytes=32 time=16ms TTL=126 Reply from 192.168.42.111: bytes=32 time=26ms TTL=126 Ping statistics for 192.168.42.111: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 16ms, Maximum = 26ms, Average = 19ms

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      Shut down the Windows firewall censored before doing any testing of any network-related stuff on any Windows box.

                      1 Reply Last reply Reply Quote 0
                      • M
                        Mando555
                        last edited by

                        @doktornotor:

                        Shut down the Windows firewall censored before doing any testing of any network-related stuff on any Windows box.

                        Firewall was on the Location C Windows Server and has been disabled for years at Locations A and B. No change with firewall disabled :'(

                        1 Reply Last reply Reply Quote 0
                        • M
                          Mando555
                          last edited by

                          Ok earlier today I figured out what the issue was!

                          The gateway on the terminals were improperly set. They were set for the Cisco gateway at 192.168.1.254. I changed it and instantly got access. Thanks again for the input!

                          1 Reply Last reply Reply Quote 0
                          • P
                            phil.davis
                            last edited by

                            For future readers, when some devices are reachable on a remote subnet across VPN but others are not, the common problems are:

                            1. The target device has its own Firewall. Often that firewall might allow access by another device directly on the subnet, but not from a remote subnet. Prime offender - Windows ****. Turn off firewall.

                            2. The target device does not have a (correct) gateway set. In that case it can answer directly on its LAN but not to anything off the LAN.

                            3. The target device has the wrong subnet mask - causing it to think the wrong range of IP addresses are local, or to not be able to reach the gateway or…

                            4. The target device is a really stupid print server or whatever that has nowhere in the firmware to even enter a gateway IP. First choice - ditch it. Second choice - NAT out onto that remote LAN so the traffic from the subnet/s on the other end of the tunnel looks like it comes from the local pfSense LAN IP.

                            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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