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

    OpenVPN on 2.3.2 "Exiting due to fatal error"

    Scheduled Pinned Locked Moved OpenVPN
    24 Posts 3 Posters 16.4k 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.
    • T
      tsmalmbe
      last edited by

      OK, you have got me there. Because this is how I have configured all my OpenVPNs always everywhere I thought this is the correct way to do it - to make sure the client connecting to the server is using the same subnet to be able to connect? This is not so?

      Security Consultant at Mint Security Ltd - www.mintsecurity.fi

      1 Reply Last reply Reply Quote 0
      • T
        tsmalmbe
        last edited by

        My server has a "tunnel network" defined, my client has that field empty. So the server assigns the tunnel network automatically to the client connected? Is this not intended behavior?

        Security Consultant at Mint Security Ltd - www.mintsecurity.fi

        1 Reply Last reply Reply Quote 0
        • H
          heper
          last edited by

          clients receive their tunnel network when connecting to a server.
          servers have a tunnel network defined in the config.

          in no circumstance should any interface have the same subnet and/or ip.

          Because this is how I have configured all my OpenVPNs always everywhere I thought this is the correct way to do it - to make sure the client connecting to the server is using the same subnet to be able to connect? This is not so?

          hmm? i'm unable to understand what you want todo.
          clients connect to a server instance. there is no point in running both a client & server instance and connecting them to themselfs ????

          a tunnel network is a transit network. It honestly doesn't matter what subnet you use, as long as it doesn't conflict with others.

          1 Reply Last reply Reply Quote 0
          • T
            tsmalmbe
            last edited by

            Summa summarum. The server component has a transit/tunnel network defined, the client configuration does not. However that translates into interface configurations, that I do not know. In no place have I defined the same network twice in any configuration.

            Security Consultant at Mint Security Ltd - www.mintsecurity.fi

            1 Reply Last reply Reply Quote 0
            • H
              heper
              last edited by

              Where does the client connect to?

              1 Reply Last reply Reply Quote 0
              • T
                tsmalmbe
                last edited by

                @heper:

                Where does the client connect to?

                I have defined one OpenVPN server and one Client. The client connects to the server.

                Security Consultant at Mint Security Ltd - www.mintsecurity.fi

                1 Reply Last reply Reply Quote 0
                • T
                  tsmalmbe
                  last edited by

                  Seems like this option makes it work. The serverprocess is able to start as well as the clientprocess.

                  net.link.ether.inet.useloopback=0

                  Does anyone know what that exactly does, and what the possible consequences might be? At the moment with that setting on, I can connect with my windowsclient to the OpenVPN server, but now I have problems with traffic.

                  WindowsPC out -> pfSense in -> pfSense out -> LAN Linux in -> LAN Linux out  -> packet lost

                  I have monitored firewall logs and used tcpdump on pfsense as well as the Linux machine. to determine where tha packet gets lost.

                  Security Consultant at Mint Security Ltd - www.mintsecurity.fi

                  1 Reply Last reply Reply Quote 0
                  • H
                    heper
                    last edited by

                    @tsmalmbe:

                    @heper:

                    Where does the client connect to?

                    I have defined one OpenVPN server and one Client. The client connects to the server.

                    why oh why would you create an openVPN-client instance, to connect to the openVPN-server instance, that is on the same physical/virtual pfSense ?????

                    mind blown

                    1 Reply Last reply Reply Quote 0
                    • T
                      tsmalmbe
                      last edited by

                      Good for me. All of my firewalls are configured with "clients" which I wrongly assumed where "clients-that-connect-to-the-server" -client definitions. So it is not. Apparently the Client Export -tab is the only thing I need for my REAL clients, the Windows PC, to connect to the server.

                      In reality, all of my defined "Clients" have never connected anywhere it seems. But for the sake of our minds not blowing up, I have now deleted all client configurations from all of my firewalls.

                      Based on this mindblowing experience and knowledge, I will start over.

                      Security Consultant at Mint Security Ltd - www.mintsecurity.fi

                      1 Reply Last reply Reply Quote 0
                      • T
                        tsmalmbe
                        last edited by

                        Right, so the connection still gets opened up. I removed the additional parameter from System -> Advanced. Still works. Of course deleted all "Clients". Still works. No traffic though. I verified that my ovpn-file for this firewall looks exactly like others that work - so I opted to download and install the latest version of the OpenVPN client for Windows. Tadaa. Now everything seem to work as expected. I suspect that part of debugging should be killing the openvpn.exe -process in windows every time, to make sure you don't have stuff interfering.

                        A learning experience.

                        Security Consultant at Mint Security Ltd - www.mintsecurity.fi

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