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

    IPsec VTI 2.6.0 requires reboot

    IPsec
    4
    10
    1.6k
    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.
    • O
      Ofloo
      last edited by

      For some reason not sure what or why, when I adjust a tunnel configuration the tunnel won't come online no matter what, until I reboot the system.

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

        What kind of adjustment isn't working?

        A reboot is unlikely to be required if settings don't appear to activate in IPsec, you can try stopping the IPsec daemon and then starting it again. Do not use 'restart' as it only refreshes the config.

        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
        • O
          Ofloo
          last edited by Ofloo

          nothing fancy i just adjusted the network range noticed that the prefix was wrong and so re-adjusted that saved.

          I did restart from the web interface and from ssh ipsec restart.

          Neither worked. Did not matter what I did the tunnel only reestablished after rebooting.

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

            @ofloo said in IPsec VTI 2.6.0 requires reboot:

            nothing fancy i just adjusted the network range noticed that the prefix was wrong and so re-adjusted that saved.

            In what setting exactly? And is it IPv4 or IPv6?

            I did restart from the web interface and from ssh ipsec restart.

            Neither worked. Did not matter what I did the tunnel only reestablished after rebooting.

            Both of those only refresh the configuration, they don't actually stop and start (and reconfigure) the IPsec daemon. If you try it again, do a stop action, wait for it to stop, then start it again.

            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!

            T 1 Reply Last reply Reply Quote 0
            • T
              timboau 0 @jimp
              last edited by

              @jimp I have stopped and started the service without any tunnels coming back up. (I have not restarted on 2.6 to try and bring them back)

              1 Reply Last reply Reply Quote 0
              • luckman212L
                luckman212 LAYER 8
                last edited by

                @timboau-0 or @Ofloo are you still having this problem? I recently started converting my policy based IPSEC tunnels to VTIs, and am encountering various strange issues. I'm running 22.05 snaps now though.

                O 1 Reply Last reply Reply Quote 0
                • O
                  Ofloo @luckman212
                  last edited by Ofloo

                  @luckman212 I've made a cron script which checks the logs for specific things then kill the ipsec tunnel added watchdog to auto restart it.

                  Not sure if that's still nessairy however that's how I run it now.

                  But I now can edit tunnels. Without having to reboot.

                  luckman212L 1 Reply Last reply Reply Quote 0
                  • luckman212L
                    luckman212 LAYER 8 @Ofloo
                    last edited by

                    @ofloo What sort of "things" are you checking for in your script?

                    O 1 Reply Last reply Reply Quote 0
                    • O
                      Ofloo @luckman212
                      last edited by Ofloo

                      @luckman212

                      #!/usr/bin/env bash
                      
                      if [ $(tail /var/log/ipsec.log | /usr/bin/grep "trap not found, unable to acquire reqid" | /usr/bin/wc -l) -gt "0" ]; then  
                       kill -9 $(cat /var/run/charon.pid) 
                       echo "Executed Charon kill script, IPsec seems locked up"
                      fi
                      
                      exit 0
                      
                      
                      luckman212L 1 Reply Last reply Reply Quote 0
                      • luckman212L
                        luckman212 LAYER 8 @Ofloo
                        last edited by

                        @ofloo Thanks. couple of small points:

                        • your shebang is for bash -- did you install bash on your firewall? (pfSense does not come with bash)
                        • you could use pkill -F /var/run/charon.pid which is more concise and doesn't need the cat
                        • wouldn't you need to tail -n10 etc to be sure you weren't just reading the same "trap not found" message over and over in a loop?
                        • you don't need the extra if-test and pipe to wc, you can test the result code from grep directly

                        maybe something like this would work? (I have not tested this)

                        #!/bin/sh
                        
                        if tail -n10 /var/log/ipsec.log | /usr/bin/grep -q "trap not found, unable to acquire reqid"; then  
                         pkill -9 -F cat /var/run/charon.pid
                         echo "Executed Charon kill script, IPsec seems locked up"
                        fi
                        
                        exit 0
                        
                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.