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

Pfsense Ipsec connections to router with DynDNS address - DNS not resolving

Scheduled Pinned Locked Moved IPsec
7 Posts 3 Posters 1.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.
  • C
    claferriere
    last edited by Jul 4, 2019, 3:59 AM

    I have an IPsec tunnel connected between two Pfsense routers/sites. These routers are only permanently accessible via DynDNS as the Upstream service on both has dynamic IP addressing. Therefore the site may be addressed by the form ipsec1.xxx.com with a Cloudflare Dyndns program running on the pfsense box maintaining the public ip address of the router with a proper CNAM DNS A record entry for the domain name "ipsec1.xxx.com". It all works fine until one of the ip addresses gets changed to a new one. All of the pfsense boxes with the Cloudflare DynDns app running update immediately to show the new IP address. DNS even resolves it properly. However, the IPsec Tunnel which uses the subdomain name ipsec1.xxx.com suddenly stops responding and will NOT resolve the new IP address.
    Can anyone explain how to ensure the ipsec tunnels can maintain the proper ip address of the ipsec.xxx.com subdomain after an ip address change from the provider without having to manually reset them one by one with the actual IP address ? Everything in pfsense can resolve the new IP address without any difficulty except the active Ipsec tunnels.
    thanks for any assistance on this matter.

    1 Reply Last reply Reply Quote 0
    • K
      kiokoman LAYER 8
      last edited by Jul 4, 2019, 8:23 AM

      afaik when you enter a hostname in ipsec config it will be converted to an IP and that will be used.
      the best solution would be to have at least one of the side with a static ip
      maybe you can try to create a cron job to restart it

      ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
      Please do not use chat/PM to ask for help
      we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
      Don't forget to Upvote with the 👍 button for any post you find to be helpful.

      1 Reply Last reply Reply Quote 0
      • C
        claferriere
        last edited by Jul 4, 2019, 12:28 PM

        I guess it could work, but I need an if then else type of cron job...if the tunnel goes down, restart, but I am not certain the DNS entry for the host name actually resolves in ipsec....
        2019-07-04_08-24-14.jpg

        1 Reply Last reply Reply Quote 0
        • K
          kiokoman LAYER 8
          last edited by Jul 4, 2019, 12:46 PM

          try

          pfSsh.php playback restartipsec
          

          and maybe you don't lose connectivity

          or

          pfSsh.php playback svc stop ipsec; pfSsh.php playback svc start ipsec
          

          maybe you can build a script with the help of

          ipsec status
          

          ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
          Please do not use chat/PM to ask for help
          we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
          Don't forget to Upvote with the 👍 button for any post you find to be helpful.

          C 1 Reply Last reply Jul 5, 2019, 4:17 PM Reply Quote 1
          • C
            claferriere @kiokoman
            last edited by Jul 5, 2019, 4:17 PM

            @kiokoman Sounds like a good solution. I would still like to know where the ipsec app gets the IP address from when the FQDN dns is resolved. The Dyndns system (Cloudflare app) running inside pfsense is flawless and resloves instantly on all pfsense boxes involved in the ipsec routes/network. But as I mentioned when the Ip address changes, nothing is updated inside ipsec...

            1 Reply Last reply Reply Quote 0
            • K
              kiokoman LAYER 8
              last edited by Jul 5, 2019, 5:02 PM

              if you check with

              cat /var/etc/ipsec/ipsec.conf
              

              you will see that ipsec have converted your host name onto an ip

              rightid = xxx.xxx.xxx.xxx
              

              if your host name change ip, ipsec does not care because it's using the previusly resolved ip and not the hostname, so you need to restart it to let it know of the change

              ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
              Please do not use chat/PM to ask for help
              we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
              Don't forget to Upvote with the 👍 button for any post you find to be helpful.

              1 Reply Last reply Reply Quote 0
              • D
                Derelict LAYER 8 Netgate
                last edited by Derelict Jul 12, 2019, 5:48 AM Jul 12, 2019, 5:40 AM

                Not true.

                right = is the address being connected to/from
                rightid = is the identifier the other side is expected to present

                If an FQDN is used in the Remote Gateway of a connection, the FQDN is used as right = that.fqdn.tld

                Strongswan says this:

                If an FQDN is assigned it is resolved every time a configuration lookup is done. If DNS resolution times out, the lookup is delayed for that time.

                The rightid could be pleasemakemyipsecwork as long as both sides agree.

                In dyndns situations it is usually necessary to set a specific identifier in My identifier (usually something like the dyndns host name of that side) on the side or sides that are suffering with dynamic addressing with a matching Remote identifier on the other side.

                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
                7 out of 7
                • First post
                  7/7
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                  This community forum collects and processes your personal information.
                  consent.not_received