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

    Routing between OpenVPN Clients / Headquarter / Site-to-Site

    Scheduled Pinned Locked Moved Routing and Multi WAN
    8 Posts 5 Posters 2.4k Views 3 Watching
    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.
    • A Offline
      andrea.pellegrinicssa.it
      last edited by

      I have a full working scenario as follow:

      • Headquarter (site A): LAN 192.168.0.0/24, Pfsense LAN Firewall (192.168.0.190), 1xWAN Interface, OpenVPN Server to enable 50 Mobile PC Connections via Client Software computers (IP class 192.168.2.0/24, firewall has 192.168.2.1 IP) and a Site-to-Site OpenVPN Server (IP class 192.168.10.0/24) to enable a bidirectional communication with a remote location (site B).
      • Remote location (site B): LAN 192.168.126.0/24, PFSense LAN Firewall (192.168.126.254), 1xWAN interface, OpenVPN Client (Firewall OpenVPN IP 192.168.10.2) to enable bidirectional comunication with Headquarter (Firewall OpenVPN server IP 192.168.10.1).
        from Headquarter LAN I can reach both OpenVPN clients,

      What I need now is to be able to reach the network with IP class 192.168.126.0/24 from the network with IP class 192.168.2.0/24 and viceversa. How can I do?

      Thanks for help.

      PS: PFSense is at last version.

      1 Reply Last reply Reply Quote 0
      • V Offline
        viragomann
        last edited by

        On site B site-to-site settings add 192.168.2.0/24 to the "Remote Networks" to get the traffic routed over the vpn.
        On site A in access server settings add 192.168.126.0/24 to the "Local Networks" to get the route for this network pushed to the clients.

        For the site-to-site vpn you should have assigned interfaces at both sites.
        Ensure that your firewall rules allow the access between the networks.

        1 Reply Last reply Reply Quote 0
        • A Offline
          andrea.pellegrinicssa.it
          last edited by

          I was trying what you suggested but I have a problem. Applying first two configurations all continue working well, but when I try to assign interfaces in site A, adding firewall rules, the comunication between site A and site B stops, also if the VPN is up.
          Can you suggest me more specifically what I have to do? Can you tell me in which interface I have to configure firewall rules?

          Thank you

          1 Reply Last reply Reply Quote 0
          • V Offline
            viragomann
            last edited by

            Just assign an interface to the openvpn stite to site server at A, open the interface settings and enable it. You also may set a name if you like, but do no further configurations, no IP settings!
            Also assign an interface to the openvpn client at B this way.

            Consider that firewalls rule on the interfaces control incoming traffic. So if you want to allow access from site B LAN to A LAN you need a firewall rule on the LAN interface at B which allow the traffic and also you need a rule on the newly added vpn interface at A allowing the traffic.

            1 Reply Last reply Reply Quote 0
            • T Offline
              techvic
              last edited by techvic

              I dig out this old thread because I'm facing the exact same issue.

              I understand everything related to the OpenVPN-config. My problems start when I assign interfaces to the OpenVPN-Servers (communication is blocked as soon I enable the interfaces). I tried to create firewall rules to allow that traffic, but unfortunately it's not clear enough what rule I need on which interface.

              Can someone explain in detail what rules need to be created? To make it easier for others following this thread, it would be enough for me to have the rules explained on the IP-subnet examples from above

              1 Reply Last reply Reply Quote 0
              • T Offline
                techvic
                last edited by

                ok with playing around I found the culprit for all communications blocked: the OpenVPN-Server-Instances had to be restarted for the new firewall rules to take effect on them.

                So now the direct communication from remote site (B) to Server site (A) works, as well as from Mobile Clients (in aboves example IP net 192.168.2.0/24) to site A.

                However, what still is not working, is from a Mobile Client to remote site B.

                For testing, I set the corresponding firewall rules on the "source" to "any", but still no way from 192.168.2.0/24 to 192.168.126.0/24.

                Ain't there some routing required?

                S 1 Reply Last reply Reply Quote 0
                • S Offline
                  stephentw @techvic
                  last edited by

                  @techvic You may need to configure Site B so that it knows to route traffic (responses mostly in my experience) through the Site A <-> Site B vpn connection. I had a very similar situation, although we were using TINC for the site-to-site and OpenVPN for remote access. Once I told the TINC connection on Site B to route traffic going to the remote access subnet through the Site A <-> Site B VPN, it worked great.

                  1 Reply Last reply Reply Quote 0
                  • M Offline
                    marvosa
                    last edited by

                    @techvic I don't know if you eventually got everything worked out, but at a high level, what needs to happen is the mobile clients @ site A have to know that site B's LAN is accessible thru the tunnel and site B needs to know that site A's remote access tunnel network is accessible thru the tunnel.

                    Also, assigned interfaces are not required to get this working. The routing is generated by OpenVPN behind the scenes based on the options provided in the GUI.

                    If your issue is resolved at this point, great. If not, I would start a new thread.

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