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

    Upgraded to 2.4.3, OpenVPN tunnel cannot be established anymore

    Scheduled Pinned Locked Moved OpenVPN
    14 Posts 3 Posters 2.0k 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
      RickTosch
      last edited by RickTosch

      At least I am getting something the client logs now.

      RESOLVE: Cannot resolve host address: mydomainname:12222 (hostname nor servname provided, or not known)
      

      I can only deduct from this that my server pfsense box is not accepting connections from the client on port 12222? I say that because I am able to access other services on this very domain name/IP. Strange because I havent done anything and I believe there is a rule (WAN) on the server pfsense to accept connections on that port.

      1 Reply Last reply Reply Quote 0
      • R
        RickTosch
        last edited by

        and another update. I now see that I cannot seem to resolve anything via the Diagnostics->DNS Lookup because.
        127.0.0.1 appears to be the only DNS server on the dashboard.

        1 Reply Last reply Reply Quote 0
        • R
          RickTosch
          last edited by RickTosch

          Alright, this topic can be archived and I feel very silly.It ended up being a DNS issue. Obviously 127.0.0.1 being the only DNS server for pfSense internally couldn't resolve the external domain name so after I gave it another DNS server, the tunnel automatically took on.

          I suppose that perhaps the DNS settings did not get carried over from backup XML when I restored the client.

          Thanks

          1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator
            last edited by

            No that is not the reason - the loopback listing for dns is the correct out of the box default configuration of pfsense - since out of the box pfsense resolves via unbound. So pfsense wanting to "resolve" something yes it should just ask itself via loopback.

            mydomainname:12222

            Is not a valid FQDN- that would never resolve.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            R 1 Reply Last reply Reply Quote 0
            • R
              RickTosch @johnpoz
              last edited by

              @johnpoz hey there,
              that is not the full domain name, more of an example. I changed it for obvious reasons.
              However, I couldn't even resolve something like microsoft.com so perhaps I have things setup incorrectly?

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by johnpoz

                If you go to pfsense diag, dns lookup and you can not resolve microsoft.com then sure you have a problem. Maybe your isp is blocing dns resolving, maybe your on a horrible connection for latency like sat or something and resolving timesout, etc.

                Anything with :1234 on the end of il wil never resolve since its not a valid fqdn no matter if you changed the mydoamin part or not

                0_1531338871199_dnslookup.png

                If you PM me the actual fqdn your wanting to resolve I will validate it resolves on the public internet. Via unbound - unbound out the box will also not return something that fails dnssec, etc.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                R 1 Reply Last reply Reply Quote 0
                • R
                  RickTosch @johnpoz
                  last edited by

                  @johnpoz said in Upgraded to 2.4.3, OpenVPN tunnel cannot be established anymore:

                  dns re

                  Thank you John,
                  I do not think we are on the same page here. While I appreciate what you are saying, that is not what I did (try resolving something with a port number). You must be confusing my post with an OpenVPN LOG entry:

                  RESOLVE: Cannot resolve host address: mydomainname:12222 (hostname nor servname provided, or not known)
                  

                  which has nothing to do with me using Diagnostics-> DNS Resolve.

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by

                    Can you resolve the FQDN or not?

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    1 Reply Last reply Reply Quote 0
                    • R
                      RickTosch
                      last edited by RickTosch

                      Yes I can now, after adding 2 additional DNS servers under General setting.
                      I couldn't do so otherwise with only 127.0.0.1

                      1 Reply Last reply Reply Quote 0
                      • chpalmerC
                        chpalmer
                        last edited by

                        Is your Unbound service actually running- /status_services.php

                        Triggering snowflakes one by one..
                        Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

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