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

    3 offices, OpenVPN clients cannot communicate with remote offices

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 1.3k 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.
    • R
      Rubicon
      last edited by

      I've been searching through the forums for an answer and believed I've found it however I just cannot get this to work.  We have 3 offices using 3 different routers currently.  Office 1 uses Cisco ASA, Office 2 uses pfSense and office 3 uses a Netgear Business router/firewall.

      Office 1 (10.200.0.0/16) <–IPSEC-->  Office 2 (192.168.50.0/23) <--IPSEC--> Office 3 (192.168.4.0/23)

      Office 2 is using pfSense and OpenVPN for its staff.  This is the office in question.  the pfSense IPSEC between all 3 offices works great and each can communicate.  This issue that comes into play is the Office 2 has OpenVPN clients.  Their IP Pool is 192.168.53.0/24.  On the OpenVPN server the following settings are in place:

      IPv4 Local Network/s - 192.168.50.0/23,192.168.4.0/23,10.200.0.0/16
      Advanced Config - push "route 192.168.50.0 255.255.254.0";push "route 192.168.4.0 255.255.254.0";push "route 10.200.0.0 255.255.0.0";

      When OpenVPN client connect to the server, they can only communicate with the 192.168.50.0/23 subnet and no other office.  The IPSEC works fine from within the building, just not external OpenVPN clients.

      On office 1 and office 3's end, theres phase 2 rules on the IPSEC to account for both the 192.168.50.0/23 and 192.168.53.0/24 subnets.

      I'm confused as to why these openVPN clients cannot communicate with anyone outside their own office (2).  I've even tested with having the firewall for the openvpn and ipsec wide open and that did not help.  I only did this to test to make sure my rules were not effecting it, but it was a no go.

      Any ideas would be greatly appreciated :)

      Thanks!
      vpn.JPG
      vpn.JPG_thumb

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

        IPv4 Local Network/s - 192.168.50.0/23,192.168.4.0/23,10.200.0.0/16
        Advanced Config - push "route 192.168.50.0 255.255.254.0";push "route 192.168.4.0 255.255.254.0";push "route 10.200.0.0 255.255.0.0";

        Just a comment that those push route advanced statements are no longer needed from 2.1 onwards. The list in Local Network/s generates a push route for each network in the list. But I don't expect that having those in there will break it.
        The words you say about IPsec Phase2 entries sound good - that is usually the problem others have had, getting the remote offices to know about the existence of the OpenVPN "Road Warrior" subnet across the IPsec link. I am no IPsec expert, so will leave it to someone else to think of likely issues.

        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
        • R
          Rubicon
          last edited by

          I tried removing the advance config but still have the same issue.  Is there something I need to do on the IPSEC connections to each remote office?

          Hopefully someone has an idea to go off of?

          1 Reply Last reply Reply Quote 0
          • R
            Rubicon
            last edited by

            Also noticed that if an OpenVPN client does an ipconfig /all, no gateway is filled in.  Should one be there?  I would assume so…no?

            Route Print:

            IPv4 Route Table

            Active Routes:
            Network Destination        Netmask          Gateway      Interface  Metric
                  10.200.0.0      255.255.0.0    192.168.53.1    192.168.53.2    30
                    127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
                    127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
              127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
                  192.168.4.0    255.255.254.0    192.168.53.1    192.168.53.2    30
                192.168.50.0    255.255.254.0    192.168.53.1    192.168.53.2    30
                192.168.53.0    255.255.255.0        On-link      192.168.53.2    286
                192.168.53.2  255.255.255.255        On-link      192.168.53.2    286
              192.168.53.255  255.255.255.255        On-link      192.168.53.2    286
                    224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
                    224.0.0.0        240.0.0.0        On-link  192.168.116.112    266
                    224.0.0.0        240.0.0.0        On-link      192.168.53.2    286
              255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
              255.255.255.255  255.255.255.255        On-link  192.168.116.112    266
              255.255.255.255  255.255.255.255        On-link      192.168.53.2    286

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

              Here is an example of me on 192.168.44.0/22 with an OpenVPN working through tunnel 10.50.32.0/24 to networks 10.49.0.0/16 and 10.51.0.0/16
              I still have a default route (0.0.0.0) to my real internet gatewayat 192.168.44.250 - it is rather odd that your client can establish the OpenVPN connection but not actually have a default route at the top of the list! but at least the other routes to the various office subnets across the OpenVPN tunnel are there.

              IPv4 Route Table
              ===========================================================================
              Active Routes:
              Network Destination        Netmask          Gateway       Interface  Metric
                        0.0.0.0          0.0.0.0   192.168.44.250     192.168.47.3     20
                      10.49.0.0      255.255.0.0       10.50.32.5       10.50.32.6     30
                     10.50.32.1  255.255.255.255       10.50.32.5       10.50.32.6     30
                     10.50.32.4  255.255.255.252         On-link        10.50.32.6    286
                     10.50.32.6  255.255.255.255         On-link        10.50.32.6    286
                     10.50.32.7  255.255.255.255         On-link        10.50.32.6    286
                      10.51.0.0      255.255.0.0       10.50.32.5       10.50.32.6     30
                      127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
                      127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
                127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
                   192.168.44.0    255.255.252.0         On-link      192.168.47.3    276
                   192.168.47.3  255.255.255.255         On-link      192.168.47.3    276
                 192.168.47.255  255.255.255.255         On-link      192.168.47.3    276
                   192.168.56.0    255.255.255.0         On-link      192.168.56.1    276
                   192.168.56.1  255.255.255.255         On-link      192.168.56.1    276
                 192.168.56.255  255.255.255.255         On-link      192.168.56.1    276
                      224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
                      224.0.0.0        240.0.0.0         On-link      192.168.56.1    276
                      224.0.0.0        240.0.0.0         On-link      192.168.47.3    276
                      224.0.0.0        240.0.0.0         On-link        10.50.32.6    286
                255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
                255.255.255.255  255.255.255.255         On-link      192.168.56.1    276
                255.255.255.255  255.255.255.255         On-link      192.168.47.3    276
                255.255.255.255  255.255.255.255         On-link        10.50.32.6    286
              ===========================================================================
              Persistent Routes:
                None
              

              I really expect it will be an issue with IPsec phase2 and successfully telling the other offices the route back to the OpenVPN road warrior tunnel subnet.

              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
              • R
                Rubicon
                last edited by

                Thanks for the reply.  We ended up resolving the issue on Monday and it was indeed an issue with the phase2.  It was a problem with the route coming from the Cisco router and the Netgear.  Everything was good in pfSense, just had to get the configs right on the other ends.  We just had 1 thing on each crossed up.  Thanks guys!

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