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

    VPN IPsec Remote gateway using DDNS doesn't update

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    30 Posts 6 Posters 17.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.
    • jimpJ
      jimp Rebel Alliance Developer Netgate
      last edited by

      Should be fixed in new snaps.

      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

      Need help fast? Netgate Global Support!

      Do not Chat/PM for help!

      1 Reply Last reply Reply Quote 0
      • C
        cyboc
        last edited by

        Thanks Jimp,

        I also just noticed another error message in the build 2.0-BETA5  (i386) built on Mon Jan 31 07:16:37 EST 2011. I don't know if it is already fixed in the next snaps but I thought I should report it anyway.

        When I uncheck "Enable IPSec", hit Save, then check "Enable IPSec" and hit Save again, I see the following error message at the top of the page:

        Warning: Invalid argument supplied for foreach() in /etc/inc/vpn.inc on line 908
        

        You can see it in the attached screenshot.

        Here is the code in that spot, it it helps:

        
        /* start filterdns, if necessary */
        if (count($filterdns_list) > 0) {
          $interval = 60;
          if (!empty($ipseccfg['dns-interval']) && is_numeric($ipseccfg['dns-interval']))
            $interval = $ipseccfg['dns-interval'];
        
          $hostnames = "";
          array_unique($filterdns_list);
          foreach ($hostname as $filterdns_list) ###### <---line 908
            $hostnames .= "cmd {$hostname} '/etc/rc.newipsecdns'\n";
          file_put_contents("{$g['varetc_path']}/filternds-ipsec.hosts", $hostnames);
        
          killbypid("{$g['varrun_path']}/filterdns-ipsec.pid");
          mwexec("/usr/local/sbin/filterdns -p {$g['varrun_path']}/filterdns-ipsec.pid -i {$interval} -c {$g['varetc_path']}/filterdns-ipsec.hosts -d 1");
        }
        

        InvalidArgument-vpninc.PNG
        InvalidArgument-vpninc.PNG_thumb

        1 Reply Last reply Reply Quote 0
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          Fixed now.

          That should have been:

          foreach ($filterdns_list as $hostname)
          

          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

          Need help fast? Netgate Global Support!

          Do not Chat/PM for help!

          1 Reply Last reply Reply Quote 0
          • C
            cyboc
            last edited by

            Hi Jimp,

            Thanks for your very quick response. I applied your changes locally, in advance of the next snapshots. The error messages are now gone from the system log and from the IPSec config page. However, when the IP address on the dynamic side of the tunnel changes, the tunnel does not come back up. The change is detected by filterdns (because the system log shows "php: : IPSEC: One or more IPSEC tunnel endpoints has changed IP. Refreshing.") but the tunnel just does not come back up.

            Attached are a series of obfuscated screenshots from both the static side and the dynamic before and after the dyndns IP address change. The address of the dynamic side was changed from x.x.x.198 to x.x.x.195. The address of the static side is 216.x.x.x. The are a lot of screenshots so please pay close attention to the words "staticSide", "dynamicSide", "Before" and "After" in the file names to figure out which is which.

            (the screenshots are spread out over the next couple of posts because of attachment limits in this forum)

            It is interesting to note that after the address change, the racoon service on the static side stopped, as shown in the screenshot "staticSide-ServicesStatus-AfterDyndnsChange.PNG". To get the tunnel back up, I had to start the stopped racoon service on the static side and restart the running racoon service on the dynamic side.

            staticSide-IPSecStatus-BeforeDyndnsChange.PNG
            staticSide-IPSecStatus-BeforeDyndnsChange.PNG_thumb
            staticSide-IPSecSAD-BeforeDyndnsChange.PNG
            staticSide-IPSecSAD-BeforeDyndnsChange.PNG_thumb
            staticSide-IPSecSPD-BeforeDyndnsChange.PNG
            staticSide-IPSecSPD-BeforeDyndnsChange.PNG_thumb
            staticSide-IPSecLog-BeforeDyndnsChange.PNG
            staticSide-IPSecLog-BeforeDyndnsChange.PNG_thumb

            1 Reply Last reply Reply Quote 0
            • C
              cyboc
              last edited by

              more screeshots

              dynamicSide-IPSecStatus-BeforeDyndnsChange.PNG
              dynamicSide-IPSecStatus-BeforeDyndnsChange.PNG_thumb
              dynamicSide-IPSecSAD-BeforeDyndnsChange.PNG
              dynamicSide-IPSecSAD-BeforeDyndnsChange.PNG_thumb
              dynamicSide-IPSecSPD-BeforeDyndnsChange.PNG
              dynamicSide-IPSecSPD-BeforeDyndnsChange.PNG_thumb
              dynamicSide-IPSecLog-BeforeDyndnsChange.PNG
              dynamicSide-IPSecLog-BeforeDyndnsChange.PNG_thumb

              1 Reply Last reply Reply Quote 0
              • C
                cyboc
                last edited by

                even more screenshots

                staticSide-IPSecStatus-AfterDyndnsChange.PNG
                staticSide-IPSecStatus-AfterDyndnsChange.PNG_thumb
                staticSide-IPSecSAD-AfterDyndnsChange.PNG
                staticSide-IPSecSAD-AfterDyndnsChange.PNG_thumb
                staticSide-IPSecSPD-AfterDyndnsChange.PNG
                staticSide-IPSecSPD-AfterDyndnsChange.PNG_thumb
                staticSide-IPSecLog-AfterDyndnsChange.PNG
                staticSide-IPSecLog-AfterDyndnsChange.PNG_thumb
                staticSide-ServicesStatus-AfterDyndnsChange.PNG
                staticSide-ServicesStatus-AfterDyndnsChange.PNG_thumb
                staticSide-SystemLog-AfterDyndnsChange.PNG
                staticSide-SystemLog-AfterDyndnsChange.PNG_thumb

                1 Reply Last reply Reply Quote 0
                • C
                  cyboc
                  last edited by

                  Last set of screenshots. Phew!

                  dynamicSide-IPSecStatus-AfterDyndnsChange.PNG
                  dynamicSide-IPSecStatus-AfterDyndnsChange.PNG_thumb
                  dynamicSide-IPSecSAD-AfterDyndnsChange.PNG
                  dynamicSide-IPSecSAD-AfterDyndnsChange.PNG_thumb
                  dynamicSide-IPSecSPD-AfterDyndnsChange.PNG
                  dynamicSide-IPSecSPD-AfterDyndnsChange.PNG_thumb
                  dynamicSide-IPSecLog-AfterDyndnsChange.PNG
                  dynamicSide-IPSecLog-AfterDyndnsChange.PNG_thumb
                  dynamicSide-ServicesStatus-AfterDyndnsChange.PNG
                  dynamicSide-ServicesStatus-AfterDyndnsChange.PNG_thumb

                  1 Reply Last reply Reply Quote 0
                  • C
                    cegner
                    last edited by

                    I'm encountering the same problem. Did you find a solution for it?

                    Christof

                    1 Reply Last reply Reply Quote 0
                    • C
                      cyboc
                      last edited by

                      @cegner:

                      I'm encountering the same problem. Did you find a solution for it?

                      Christof

                      Did you try the latest firmware version?

                      1 Reply Last reply Reply Quote 0
                      • C
                        cegner
                        last edited by

                        Yes, but the problem still exists.

                        2.0-RC1 (i386)
                        built on Fri Mar 4 23:09:48 EST 2011

                        1 Reply Last reply Reply Quote 0
                        • E
                          eri--
                          last edited by

                          Please post again te system logs and ipsec logs

                          1 Reply Last reply Reply Quote 0
                          • C
                            cegner
                            last edited by

                            Here you go.

                            At 04:00 the PPPoE connection was terminated. After the reconnect the IPSEC tunnel does not come up again (for hours) without a reload as the remote peer IP address has changed. It does not seem to lookup the hostname again.

                            Mar  7 03:20:37 fw racoon: INFO: initiate new phase 2 negotiation: X.X.219.99[500]<=>X.X.197.44[500]
                            Mar  7 03:20:37 fw racoon: INFO: IPsec-SA expired: ESP/Tunnel X.X.197.44[500]->X.X0.219.99[500] spi=143188784(0x888e330)
                            Mar  7 03:20:37 fw racoon: INFO: IPsec-SA established: ESP X.X.219.99[500]->X.X.197.44[500] spi=201427959(0xc018bf7)
                            Mar  7 03:20:37 fw racoon: INFO: IPsec-SA established: ESP X.X.219.99[500]->X.X.197.44[500] spi=13656620(0xd0622c)
                            Mar  7 04:00:13 fw racoon: INFO: caught signal 15
                            Mar  7 04:00:13 fw racoon: INFO: racoon process 30653 shutdown
                            Mar  7 04:00:20 fw racoon: INFO: @(#)ipsec-tools 0.8.0.RC (http://ipsec-tools.sourceforge.net)
                            Mar  7 04:00:20 fw racoon: INFO: @(#)This product linked OpenSSL 0.9.8n 24 Mar 2010 (http://www.openssl.org/)
                            Mar  7 04:00:20 fw racoon: INFO: Reading configuration from "/var/etc/racoon.conf"
                            Mar  7 04:00:20 fw racoon: INFO: X.X.200.246[4500] used for NAT-T
                            Mar  7 04:00:20 fw racoon: INFO: X.X.200.246[4500] used as isakmp port (fd=19)
                            Mar  7 04:00:20 fw racoon: INFO: X.X.200.246[500] used for NAT-T
                            Mar  7 04:00:20 fw racoon: INFO: X.X.200.246[500] used as isakmp port (fd=20)
                            Mar  7 04:00:20 fw racoon: INFO: unsupported PF_KEY message REGISTER
                            Mar  7 04:00:20 fw racoon: ERROR: such policy already exists. anyway replace it: 192.168.1.254/32[0] 192.168.1.0/24[0] proto=any dir=out
                            Mar  7 04:00:20 fw racoon: ERROR: such policy already exists. anyway replace it: 192.168.1.0/24[0] 192.168.1.254/32[0] proto=any dir=in
                            Mar  7 04:00:20 fw racoon: ERROR: such policy already exists. anyway replace it: 192.168.1.0/24[0] 192.168.10.0/24[0] proto=any dir=out
                            Mar  7 04:00:20 fw racoon: ERROR: such policy already exists. anyway replace it: 192.168.10.0/24[0] 192.168.1.0/24[0] proto=any dir=in
                            Mar  7 04:00:29 fw racoon: INFO: IPsec-SA request for X.X.197.44 queued due to no phase1 found.
                            Mar  7 04:00:29 fw racoon: INFO: initiate new phase 1 negotiation: X.X.200.246[500]<=>X.X.197.44[500]
                            Mar  7 04:00:29 fw racoon: INFO: begin Aggressive mode.
                            Mar  7 04:01:01 fw racoon: [X.X.197.44] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP X.X.197.44[0]->X.X.200.246[0]
                            Mar  7 04:01:01 fw racoon: INFO: delete phase 2 handler.
                            Mar  7 04:01:19 fw racoon: ERROR: phase1 negotiation failed due to time up. 1f856cf72bf9c322:0000000000000000
                            Mar  7 04:04:55 fw racoon: INFO: IPsec-SA request for X.X.197.44 queued due to no phase1 found.
                            Mar  7 04:04:55 fw racoon: INFO: initiate new phase 1 negotiation: X.X.200.246[500]<=>X.X.197.44[500]
                            Mar  7 04:04:55 fw racoon: INFO: begin Aggressive mode.
                            Mar  7 04:05:26 fw racoon: [X.X.197.44] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP X.X.197.44[0]->X.X.200.246[0]

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