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

    remote access openvpn cannot access the remote site of the site-to-site openvpn setup

    Scheduled Pinned Locked Moved OpenVPN
    20 Posts 3 Posters 3.1k 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.
    • bingo600B
      bingo600 @be7taname
      last edited by

      @be7taname

      So it seems like your routes are in place.

      You say you can ping from D to a Server on B , but not a server on A.

      Can you ping from D:

      10.2.105.1

      and

      10.2.105.2

      If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

      pfSense+ 23.05.1 (ZFS)

      QOTOM-Q355G4 Quad Lan.
      CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
      LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

      B 1 Reply Last reply Reply Quote 0
      • B
        be7taname @bingo600
        last edited by

        @bingo600
        This is very interesting.

        on Site-B, diagnostic->routes shows that the Gateway for LAN-A subnet is 10.2.105.1.
        I tried to ping 10.2.105.1 from Home-D so many times, it never worked.
        I never ping 10.2.105.2 from D before. It actually works.

        I thought from D the traffics have to go through 10.2.105.1 before reaching 10.2.105.2, I was seriously wrong then. Please advice. Thanks.

        bingo600B 1 Reply Last reply Reply Quote 0
        • bingo600B
          bingo600 @be7taname
          last edited by bingo600

          @be7taname

          If you can't ping 10.2.105.1 (Site A OpenVPN interface) , from D.
          Then something is "fishy" (like A doesn't know the correct route to D ... via B)

          Can you ping (from A)

          192.168.30.1
          and
          192.168.30.2 (if that is what your D client gets)

          IP traffic always goes via "next hop" (what the route table points at)

          A packet from D (192.168.30.2) to A goes (passes) ... Should pass

          D     ->    B   ->     B ->   A
          192.168.30.2  -> 192.168.30.1 -> 10.2.105.2 -> 10.2.105.1
          

          If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

          pfSense+ 23.05.1 (ZFS)

          QOTOM-Q355G4 Quad Lan.
          CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
          LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

          B 1 Reply Last reply Reply Quote 0
          • B
            be7taname @bingo600
            last edited by

            @bingo600
            from site-A, I cannot ping either 192.168.30.1 or 192.168.30.2 (and yes, that is what the D client gets).

            To summarize the experiments,

            1. when send traffic from D to A, it seems to lost at 10.2.105.1 as shown below (xxx means not working).
              192.168.30.2 ----> 192.168.30.1 ----> 10.2.105.2 --xxx--> 10.2.105.1
            2. when send traffic from A to D (to be specific: tracert 192.168.30.1 from a server at A),
              the packet seems not to go anywhere, just stopped at pfsense server.
              But I do have site-A diagnostics->routes showing that for destination 192.168.30.0/24, the gateway is 10.2.105.2.

            What do you think could be the issue? Thanks!

            bingo600B 1 Reply Last reply Reply Quote 0
            • bingo600B
              bingo600 @be7taname
              last edited by bingo600

              @be7taname

              I think site A can not forward packets to 192.168.30.0/24
              Or they are being blocked somewhere

              You have previously written that the route looks good on A

              on A ... Via B (S2S VPN tunnel)
              Destination of 192.168.30.0/24 has 10.2.105.2 as Gateway, which is also LAN-B's Gateway
              

              And that you see no blocks in the firewalls.
              So you have permitted all nets on the A-B OpenVPN interfaces.

              Based on that "it should" work

              I'm out of ideas here

              If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

              pfSense+ 23.05.1 (ZFS)

              QOTOM-Q355G4 Quad Lan.
              CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
              LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

              B 1 Reply Last reply Reply Quote 0
              • B
                be7taname @bingo600
                last edited by

                @bingo600
                Hello, I hope that you still remember this post. And thank you so much for your help. I have been debugging on and off and finally I believe I may find out the reason.

                The root cause is that the iroute of the server A is not properly set. Even though, I encountered a problem and can't fix it. :(

                Using GUI, I did create a Client Specific Overrides with 192.168.30.0/24. Somehow it doesn't work (a bug for pfsense 2.4.2-RELEASE-p1?). So I ssh as root/admin into the server A and try to modify the configure file under /var/etc/openvpn-csc/ using vi command to add 192.168.30.0. Even though I am the owner of the file and have the write permission. vi told me this is a read-only file when I was trying to save it and suggested to use :w!. I used :w! and was told the operation is not permitted. I am again out of idea now.

                If you still understand my problem and have any suggestions, please let me know. Many thanks!

                D 1 Reply Last reply Reply Quote 0
                • D
                  divsys @be7taname
                  last edited by

                  @be7taname I was looking back over this thread and didn't notice whether you're using
                  TLS/SSL or a PreSharedKey for your client-server connections. Are your OpenVPN Servers all running on pfSense boxes? I take it at least some of the clients are on PC'S/MAC's/etc?

                  As a general aside, what you're describing is not out of the ordinary at all and should be relatively straightforward. I have at least one site with a "central" OpenVPN server that also connects via clients to 7 other sites. If I connect via my laptop/phone/etc to the central site I get automatic access to the other sites as well. My setups are all TLS/SSL based but beyond the creation of certificates it is pretty cut and dried to setup.

                  -jfp

                  D 1 Reply Last reply Reply Quote 0
                  • D
                    divsys @divsys
                    last edited by

                    @divsys A little further diagnostic device that may be helpful:

                    8527ba86-8c2d-4cd3-bbc8-f3e36fce0af5-image.png

                    If you can fill in this table, it should give you pretty much everything you need to configure pfsense S2S and Remote Access servers via the GUI. I have never had to resort to anything on the command line side since 2.2+(??). The CSC info should only be needed for S2S server setups where there are multiple clients connecting. As I said earlier, this works very well from the GUI if you're methodical about setting it all up.

                    -jfp

                    B 1 Reply Last reply Reply Quote 0
                    • B
                      be7taname @divsys
                      last edited by

                      @divsys
                      Thank you so much for your help! I have resolved the issue already.
                      You are correct and the entire setup is not out of the ordinary. As a matter of fact, I could make it work using other pfsense server/client pairs except this particular troublesome one describing in this post.

                      I found the reason for both why the CSC Overrides in GUI not working and why I cannot modify the configure file using command line. The particular file has been set the system immutable flag schg. Even the root cannot remove or modify the file, at least not until you clear the flag. After removing the flag, everything finally works as expected.

                      Again, thank you so much for your kind help! @divsys

                      D 1 Reply Last reply Reply Quote 0
                      • D
                        divsys @be7taname
                        last edited by

                        @be7taname I've never had to climb "under the hood" with this stuff for a long time now, makes me a little suspicious that something else has been mangled in your whole process.
                        Personally, I'd consider wiping the Server/Clients on pfsense and building new ones from scratch to eliminate possible left over muck from giving you grief down the road. At least think about creating new Server/Client sets in parallel with the existing ones and do a switch over. The GUI installs of this stuff have been clean for a long time now.

                        Anyhow, I know you're probably thinking "But it WORKS I'm not touching it!" (I would too...)

                        Just my $.02

                        Glad you're up and running.

                        -jfp

                        B 1 Reply Last reply Reply Quote 0
                        • B
                          be7taname @divsys
                          last edited by be7taname

                          @divsys
                          Haha!
                          And you are right again. I am not touching it. It works now and I need a break from it. ^_^
                          Thank you for your advice. It is a valid concern. I left the part not saying why the flag was there at the first place since the entire thing is all my fault. I added it upon suggestions from others and then I forgot. I am pretty sure that this is the only thing I messed up under the hood.

                          Really appreciate your consideration!

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