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

    Access LAN behind OpenVPN client

    Scheduled Pinned Locked Moved OpenVPN
    16 Posts 4 Posters 3.7k 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.
    • S
      sebyp
      last edited by

      Hello everyone,

      I'm having a small difficulty with an obvious feature that doesn't work as expected (or the way I expect it :P )

      My setup is simple: I'm using Mikrotik routerOS as OpenVPN clients. All these clients connect to a central pfSense box.

      Behind the pfSense box we have a server subnet.

      Behind each Mikrotik box we have a LAN.

      I need to make sure that each Mikrotik's LAN is able to access the servers behind the pfSense box.

      Using the "IPv4 local network" field from "Client Specific Overrides" section I configured the servers subnet to be pushed to the Mikrotik clients (using IPv4 local network). This works fine, I'm able to see the routes in the Mikrotik clients.

      Using the "IPv4 remote network" field for each client account I hopped to achieve the return path: when a specific Mikrotik client connects via OpenVPN then pfSense automatically installs routes pointing to the other end of the tunnel, so that everyone can access the LAN subnet behind that client. Unfortunately this doesn't happen, as pfSense fails to install these routes. I've checked both from the GUI and from CLI using netstat -nr.

      Have I not understood correctly the feature or it's a configuration issue?

      Thanks!

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

        I think you've got a correct general understanding of how this is supposed to work.

        What version of pfSense are you running?

        Can you post a screenshot of the pfSense OpenVPN Server and Client Specific Override setups?

        OpenVPN is usually pretty simple to setup (especially with newer versions of pfSense) although the Mikrotik's may complicate things a bit.

        -jfp

        1 Reply Last reply Reply Quote 0
        • S
          sebyp
          last edited by

          Hi divsys,

          As requested, the information below.

          pfSense version: 2.2.3

          Attached server & client specific overrides relevant sections (didn't have any clue on how to capture the whole screen).

          Just as general comment I don't think that in this particular issue Mikrotik has any issues, since the tunnel is up and running and Mikrotik correctly installed the routes that OpenVPN pushed (at least this is how it should work according to my logic).

          Thanks again for your support.

          server.png_thumb
          server.png
          client.png_thumb
          client.png

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

            This is quite likely wrong, with the /32 netmask

            ![Screen Shot 2015-07-17 at 12.37.52 AM.png](/public/imported_attachments/1/Screen Shot 2015-07-17 at 12.37.52 AM.png)
            ![Screen Shot 2015-07-17 at 12.37.52 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-07-17 at 12.37.52 AM.png_thumb)

            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
            • S
              sebyp
              last edited by

              @Derelict, the point is that I want to allow access only to that specific server using a host route.

              Why do you think, from a technical point of view, that is wrong?

              Thanks

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

                There are far too many variables in play and too little information to make a guess.  If it were me, I would push the /24 to the clients and limit what they can access using firewall rules on the OpenVPN tab/interface.  That way, as policies change, you're not mucking about in your OpenVPN server config and are just adding/moving/changing firewall rules.

                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
                • D
                  doktornotor Banned
                  last edited by

                  As said above, use firewall rules on the OpenVPN tab, do not mess with remote networks.

                  1 Reply Last reply Reply Quote 0
                  • S
                    sebyp
                    last edited by

                    Guys, I really appreciate the input, however that /32 route is not the issue. The /24 route that pfSense is supposed to install on itself pointing to the LAN behind the Mikrotik client is the issue.

                    Any thoughts on that?

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      Sigh. pfSense has NO /24 route to install. You replaced that with the /32 nonsense. Then there's also this /30 nonsense. Just what are you trying to do there?

                      1 Reply Last reply Reply Quote 0
                      • S
                        sebyp
                        last edited by

                        LE: my bad, I've accidentally switched the pictures. I've just corrected them in the initial post. Sorry once again

                        1 Reply Last reply Reply Quote 0
                        • D
                          doktornotor Banned
                          last edited by

                          Why does not the CSC tunnel network match the tunnel network configured on the server? Just check on 3 sites and this "just works" when you do things consistently. Like

                          • topology set to subnet in OpenVPN Server settings, instead of the horrible net30 thing.
                          • no /30 anywhere in CSC
                          • no /32 anywhere at all
                          • use matching subnets across the client and server
                          • use firewall rules to limit access
                          1 Reply Last reply Reply Quote 0
                          • S
                            sebyp
                            last edited by

                            Because I would like to allocate specific /30 prefixes for specific clients.

                            1 Reply Last reply Reply Quote 0
                            • D
                              doktornotor Banned
                              last edited by

                              @sebyp:

                              Because I would like to allocate specific /30 prefixes for specific clients.

                              That's what done by default with topology net30 in the server settings (generally horrible thing and cannot see how's that desirable for the goal you want, at all…)

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

                                however that /32 route is not the issue.

                                If you know what the issue is (or is not), why are you here asking for help?

                                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
                                • D
                                  doktornotor Banned
                                  last edited by

                                  Also, if you are trying to make your life a real pain by emulating some wannabe static DHCP in OpenVPN, the CSC should allocate /30 at the end of the /24 pool. Not from the beginning! Plus, limit the number of allowed connections so that they are not assigned to someone else anyway.

                                  Finally, those tunnels must be "Peer To Peer", not Remote Access (good that we have ~4K resolution screenshot with half of the settings missing.  ::))

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    sebyp
                                    last edited by

                                    OK, so we've finally came to a conclusion: I missed the "peer to peer" vs "remote access" configuration, but now that you guys mentioned it makes perfect sense. I'll try to see what I can do and post my findings here, should anyone be interested.

                                    On a more general topic, @doktornotor, I really appreciate your suggestions and technical feedback (although I don't agree with some of them you have a fair technical point / concern). What I didn't appreciate that much was the tone and little sarcasm which I think could have been avoided.

                                    Thanks

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