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

    Routing between clients

    Scheduled Pinned Locked Moved OpenVPN
    12 Posts 4 Posters 1.9k 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.
    • G
      gazoo
      last edited by

      I'm currently using remote access (SSL/TLS+User Auth) (TUN) with a cert. Currently it does not appear that I can reach another client that is simultaneously connected to the VPN. The client is in the same subnet as my remote login, but the two cannot reach each other. My LAN is 192.168.x.y/24 and the tunnel network is 10.10.x.y/24. Me on one client I have 10.10.x.10 and the other has 10.10.x.6 and we cannot ping each other. I can however reach them via 192.168.x.y/24 (pfSense/OpenVPN server LAN). Is this a matter of just firewall rules, pushing some routes out, or a combo?

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

        Check "Inter-client communication" in the OpenVPN server config and add appropriate rules to OpenVPN interface.

        1 Reply Last reply Reply Quote 0
        • G
          gazoo
          last edited by

          Wow, that easy. I feel blah  :'(

          1 Reply Last reply Reply Quote 0
          • P
            PGalati
            last edited by

            Can this check box be accessed after the server config has been built?  I am having a similar issue and would prefer not to recreate the config if possible.

            Thanks

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              Yes.

              What I don't know is if it requires another client export or change on the client.  I doubt it.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • G
                gazoo
                last edited by

                Derelict-
                I'm still trying to see if that checkbox worked - although I think I may have tried it and it did not.

                I have another variation of this issue now. I have a site to site static key vpn with another pfsense box and the openvpn cert/password clients can't reach the remote on the site to site. I'll draw something up real quick later and show you the topology.

                1 Reply Last reply Reply Quote 0
                • G
                  gazoo
                  last edited by

                  Ok here's the diagram. Basically none of the clients can talk with each other. I'm not 100% sure about the road warrior ones yet since the checkbox, but the roadwarrior can't talk to the site to site remote.

                  openvpndiagram.jpg
                  openvpndiagram.jpg_thumb

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    The Site-to-site client will have to have firewall rules on OpenVPN (tab or assigned interface) permitting inbound traffic from the other clients.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • G
                      gazoo
                      last edited by

                      @Derelict:

                      The Site-to-site client will have to have firewall rules on OpenVPN (tab or assigned interface) permitting inbound traffic from the other clients.

                      Yes there's an allow ALL OpenVPN firewall tab rule in there

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

                        @gazoo:

                        Ok here's the diagram. Basically none of the clients can talk with each other. I'm not 100% sure about the road warrior ones yet since the checkbox, but the roadwarrior can't talk to the site to site remote.

                        You also have to push the routes of both tunnel networks to all clients if you want to communicate between different tunnels. Have you done this?

                        1 Reply Last reply Reply Quote 0
                        • G
                          gazoo
                          last edited by

                          Ok i have partial resolution. I can talk between roadwarrior/cert OpenVPN clients - I guess the checkbox did it. I will now proceed to mess with the site to site vpn access.

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            Yeah.  That checkbox is only for clients connecting to the same OpenVPN server instance so your Mobile and site-to-site will be different.  You need to make sure everyone has the routes to the other VPN server clients and that all the rules are in place.

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

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