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

    Peer to Peer routing unidirectionally

    Scheduled Pinned Locked Moved OpenVPN
    5 Posts 3 Posters 635 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.
    • A
      Aviatorpaal
      last edited by Aviatorpaal

      Description of issue:

      No clients from HQ, even the OVPN server itself reach networks at the remote site, even when routes are pushed from the server and they appear to be correct (please correct me). Remote site clients are able to reach all HQ networks from the remote site (NAS, servers, routed Internet)

      Description of network/routing:

      • pfSense gateways at both ends with minimal OpenVPN Peer to Peer setup. Configuration in screenshots below
      • Client WAN traffic at remote site is routed through OVPN connection to HQ, works brilliantly
      • Unreachable LAN clients at the remote site are at 10.10.10.0/24 and 10.20.20.0/24
      • Tunneled network is an unnecesary large /24 network, should not be relevant

      Other relevant finds:

      • The OVPN server itself is unable to ping clients at the remote site. Nothing shows up in the firewall logs at either side

      • Packet capture at the remote (client) site shows absolutely zero traffic even if the server routes traffic to its OpenVPN network address. Packet capture from HQ shows the ICMP packets on the OVPN server interface:

      Packet capture from HQ

      Other relevant settings:

      • "Allow all-rules at both ends on the OpenVPN tab (not the OpenVPN optional interface)"

      • LAN firewall rules at remote site to force all LAN traffic to use OVPN interface as the gateway

      Server settings at HQ:
      Server settings site A

      Client settings at remote site, where all traffic is routed through HQ:
      Client VPN settings

      Routes at HQ, OVPN server. Notice how the route for 10.20.20.0/24 has the IP address of the remote site OpenVPN client in the OpenVPN tunnel network listed (172.21.1.2):
      Routes at HQ server

      Routes at remote site, OVPN client:
      Routes at remote site

      I have spent tens of hours troubleshooting and reading great posts by this awesome community here and on Reddit, but I am running out of ideas. Help would be greatly appreciated

      J 1 Reply Last reply Reply Quote 0
      • J
        Jarhead @Aviatorpaal
        last edited by

        @aviatorpaal
        First, it's a peer to peer, you need to use a /30 or /31 as tunnel. Otherwise you need client specific overrides, so the tunnel is relevant actually.

        Second, you have no settings on the client side.
        Fill in the tunnel, and remote networks.
        OpenVPN sets routes for you by those settings.

        A 2 Replies Last reply Reply Quote 1
        • A
          Aviatorpaal @Jarhead
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • A
            Aviatorpaal @Jarhead
            last edited by Aviatorpaal

            @jarhead

            Thanks for suggesting this solution, I believe everything is working now!

            Netgate docs, in their configuration example unfortunately uses a /24 as the tunnel network, which led to the confusion:

            Routes are now setup as you described and I am able to ping clients from both sides of the firewalls.

            Note: I did not use the "net30" topology option, as this will be deprecated, according to pfSense:
            Screenshot 2022-10-06 at 11.26.17.png

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

              @aviatorpaal said in Peer to Peer routing unidirectionally:

              Netgate docs, in their configuration example unfortunately uses a /24 as the tunnel network, which led to the confusion:

              You should read the whole document:

              130ee8d3-92f9-40b3-a6b8-4b1da618fa12-grafik.png

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