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

    OpenVPN Tunnel Establishing but not Routing

    OpenVPN
    3
    6
    595
    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.
    • M
      mbrossar
      last edited by

      My VPN is not routing, and I can't figure out why. My apologies, but I think I need another set of eyes. I'm trying to re-establish an OpenVPN between two pfSense boxes. My main office box crashed, I had no usable back-up and have had to rebuild it from scratch. My remote office has not changed. Prior to the crash, the VPN was working great.

      The tunnel is establishing as indicated by a green check mark on the OpenVPN status screen. I have two line items in the OpenVPN routing table.

      • The Common Name is correct. The Real Address is the outside edge of the remote office with a random port number. The Target Network is the CIDR block for my remote network. It was last used within the past few minutes and continues to update.
      • The Common Name is correct. The Real Address is the outside edge of the remote office with a random port number (the same port number as the previous entry). The Target Network is the base network (e.g. xxx.xxx.xxx.0) with no subnet (e.g. no /xx). It was also last used recently and continues to update.

      I am not able to connect to or ping any host through the VPN. I have tried from the main office to the remote office and the remote office to the main office. No joy. I have tried pinging from Diagnostics|Ping from either side. No joy.

      Since the tunnel is establishing, I won't rehash the crypto settings. All that I believe to be route related are as follows:

      • IPv4 Tunnel Network is defined in the OpenVPN Server and Client Specific Overrides as 192.168.xxx.0/24.
      • IPv4 Local Network(s) is defined in the OpenVPN Server and Client Specific Overrides and contains the CIDR blocks for both the main office and the remote office.
      • The IPv4 Remote Network(s) is defined in the OpenVPN and Client Specific Overrides and contains the CIDR block for the remote office.
      • All other entries in the OpenVPN and Client Specific Overrides are the defaults.
      • I have an any/any rule for IPv4+IPv6 on the OpenVPN interface.

      I have been staring and comparing this document and the client settings for the past 3 days and can't see the error. Can anyone help? I'm sure it's a stupid little thing.

      M 1 Reply Last reply Reply Quote 0
      • M
        mbrossar @mbrossar
        last edited by

        Could a pfSense release version mismatch cause this? I just realized my remote office is still on v2.4.5-p1 while my main office has been upgraded to v21.02-p1. I thought 21.02-p1 was only targeted for the SG-3100 appliance so I didn't check the remote office (which is an SG-1100 appliance). I see that the remote office is reporting that 21.02_1 is available. I won't have tech support in that office for 2 weeks, so I can't effect the change until then.

        M 1 Reply Last reply Reply Quote 0
        • M
          mbrossar @mbrossar
          last edited by

          Pretty sure I found the issue. Under Advanced Configuration | Gateway creation, there are three choices via a radio button: Both, IPv4 or IPv6. On my client, none of these radio buttons were selected. After selecting Both, traffic started routing. I say that I'm pretty sure because I was making a number of changes, but I'm pretty sure this is the one that made the difference.

          KOMK 1 Reply Last reply Reply Quote 0
          • J
            johnnyy Banned
            last edited by

            I changed my vpn and now everything works well.

            1 Reply Last reply Reply Quote 0
            • J
              johnnyy Banned
              last edited by johnnyy

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM @mbrossar
                last edited by

                @mbrossar I've seen that before.

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