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

    OpenVPN Routing to other sites - Solved

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 1.5k 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
      RichardM
      last edited by

      Hello,

      I have inherited a network that looks like the picture below.

      Historically all computers on all sites can access each other, however users connecting to the VPN can only access the computers on site 1.

      I'd like to be able to give the VPN users access to all computers on all sites.

      On Site 1, I've added the following to the VPN Connection for the VPN Clients:

      push "route 172.29.0.0 255.255.0.0"; push "route 172.28.0.0 255.255.0.0";

      On Sites 2 and 3, I've added the following to their VPN connection for Site 1.

      route 10.0.101.0 255.255.255.0;

      When connected to the VPN I can now connect to the routers on each site, however I still cannot connect to the computers on Sites 2 and 3.

      When connected to the VPN, I get the following results:

      tracert 172.28.1.1

      Tracing route to 172.28.1.1 over a maximum of 30 hops

      1    36 ms    34 ms    33 ms  10.0.101.1     <= pfSense router at Site 1
       2   109 ms   112 ms    95 ms  172.28.1.1 <= pfSense router at Site 3

      Trace complete.

      tracert 172.28.1.2

      Tracing route to [172.28.1.2] over a maximum of 30 hops:

      1    34 ms    33 ms    34 ms  10.0.101.1     <= pfSense router at Site 1
       2    84 ms    78 ms    74 ms  10.0.2.2 <= pfSense router at Site 3
       3     *        *        *     Request timed out.
       4     *        *        *     Request timed out.

      Have you any suggestions as to where I have gone wrong?
      NetworkDiagram.png
      NetworkDiagram.png_thumb

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

        It looks pretty good, everything should know routes to everywhere else. As long as the clients themselves are using these pfSense boxes as their default gateway - hopefully the box at 172.28.1.2 has its default gateway 172.28.1.1, so it can reply successfully. Otherwise it would need specific routes in its routing table to tell it how to get to 172.29.0.0/16 172.30.0.0/16 and 10.0.101.0/24 (maybe the first 2 of these are already in the client at 172.28.1.2?) And that they are willing to respond to an ICMP echo request from 10.0.101.0/24 (maybe they have some firewall themselves that is only responding to the various 172 addresses?)
        By the traceroutes shown, you must have already had firewall rules on OpenVPN that allow the traffic from 10.0.101.0/24 to the other parts of the network.

        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
          RichardM
          last edited by

          Thanks for the reply.

          The windows firewall was disabled on the server.

          I've tried it in reverse, and that worked.

          tracert 10.0.101.3
          
          Tracing route to W7WS [10.0.101.3]
          over a maximum of 30 hops:
          
            1    <1 ms    <1 ms    <1 ms  172.28.1.1
            2    41 ms    41 ms    40 ms  10.0.2.1
            3    77 ms    76 ms    76 ms  W7WS [10.0.101.3]
          
          Trace complete.
          
          

          I then tried accessing a non Windows Server and that worked too.

          After a bit more hunting round (as I said it's a network that I've inherited very recently) there was a firewall enabled on windows servers at the remote sites by the Endpoint Security with trusted networks that didn't include the VPN Network.

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