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.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.
    • 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.