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

    OpenVPN Site-to-Site not working (routes not being set up?)

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 3 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.
    • S Offline
      soccermitchy
      last edited by

      When I try to connect to the VPN server from the client (both running pfsense), I get these errors on the client:

      May 23 20:28:13     openvpn     55415   /sbin/ifconfig ovpnc1 10.3.0.2 10.3.0.1 mtu 1500 netmask 255.255.255.0 up  
May 23 20:28:13     openvpn     55415   ERROR: FreeBSD route add command failed: external program exited with error status: 1  
May 23 20:28:13     openvpn     55415   /usr/local/sbin/ovpn-linkup ovpnc1 1500 1589 10.3.0.2 255.255.255.0 init  
May 23 20:28:13     openvpn     55415   ERROR: FreeBSD route add command failed: external program exited with error status: 1

      I'm pretty sure we don't have any conflicting subnets, but here are the settings we have for the client and server:

      Client:

      • Server mode: Peer to Peer (SSL/TLS)

      • Device mode: tun

      • Interface: WAN

      • Encryption algorithm: AES-256-CBC

      • Auth digest algorithm: SHA1

      • IPv4 Tunnel Network: 10.3.0.0/24

      • IPv4 Remote Network: 10.0.0.0/24

      Server:

      • Server mode: Peer to Peer (SSL/TLS)

      • Device mode: tun

      • Interface: WAN

      • Encryption algorithm: AES-256-CBC

      • Auth digest algorithm: SHA1

      • IPv4 Tunnel Network: 10.3.0.0/24

      • IPv4 Local Network: 10.0.0.0/24

      • IPv4 Remote networks: 10.2.0.0/24

      Also, on the client, the LAN interface uses 10.2.0.0/24. What could we do to fix this issue?

      1 Reply Last reply Reply Quote 0
      • M Offline
        marvosa
        last edited by

        Post your server1.conf and client1.conf

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

          The routes look like they already exist in the routing table. Disable that OpenVPN client instance and check Diagnostics > Routes. Is anything that would contain 10.3.0.2 already there?

          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 Offline
            soccermitchy
            last edited by

            Sorry for the late reply. I just uploaded my .conf files at https://screenshits.nofla.me/client1.txt and https://screenshits.nofla.me/server1.txt. In Diagnostics -> Routes, nothing that would contain 10.3.0.2 is there with OpenVPN stopped.

            1 Reply Last reply Reply Quote 0
            • M Offline
              marvosa
              last edited by

              As we progress, it looks like we need you to define for us what "not working" means in your case.  Is the tunnel connecting, but you can't communicate with any remote devices?  Or is the tunnel not coming up at all?

              A few things I see right off the bat:

              • In a routed tunnel, all subnets on both sides need to be unique and it looks like there may be either some overlap, a typo or possibly a misunderstanding.  In your OP, you stated the client's LAN was 10.2.0.0/24, but per the client's config, the client's WAN has an address of 10.2.0.1, which tells me the client's PFsense box is double NAT'd behind another edge device (not recommended), which may need to be addressed first depending on what's "not working".

              • On the server side, the server is routing 10.2.0.0/24 down the tunnel, but that is the LAN behind the client's current edge device… that's not the LAN behind PFsense.  You will need to acquire the LAN subnet behind PFsense and adjust the "IPv4 Remote network(s)" line accordingly.

              • The two sites have mismatched device modes.  The client is using device mode "TAP" while the server is using device mode "TUN".  In a routed solution, the device mode needs to be "TUN".

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

                And instead of saying "nothing that would contain 10.3.0.2 is there with OpenVPN stopped" just post your routes and we will decide that for ourselves.

                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 Offline
                  soccermitchy
                  last edited by

                  In a routed tunnel, all subnets on both sides need to be unique and it looks like there may be either some overlap, a typo or possibly a misunderstanding.  In your OP, you stated the client's LAN was 10.2.0.0/24, but per the client's config, the client's WAN has an address of 10.2.0.1, which tells me the client's PFsense box is double NAT'd behind another edge device (not recommended), which may need to be addressed first depending on what's "not working".

                  Just fixed that, accidentally selected the LAN interface for it instead of WAN.

                  On the server side, the server is routing 10.2.0.0/24 down the tunnel, but that is the LAN behind the client's current edge device… that's not the LAN behind PFsense.  You will need to acquire the LAN subnet behind PFsense and adjust the "IPv4 Remote network(s)" line accordingly.

                  Guessing that was fixed by fixing the interface issue?

                  The two sites have mismatched device modes.  The client is using device mode "TAP" while the server is using device mode "TUN".  In a routed solution, the device mode needs to be "TUN".

                  Just fixed that on the client, didn't fix anything

                  Here's my routes without the VPN connected:

                  Destination Gateway Flags Use Mtu Netif Expire
                  default 66.229.104.1 UGS 913103 1500 bge0
                  10.2.0.0/24 link#2 U 2468145 1500 bge1
                  10.2.0.1 link#2 UHS 0 16384 lo0
                  66.229.104.0/21 link#1 U 5409 1500 bge0
                  66.229.107.166 link#1 UHS 0 16384 lo0
                  127.0.0.1 link#6 UH 0 16384 lo0

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