Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 5 subscribers
  • Views 9269 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec VPN does not work for IOS devices after upgrade to 9.411-3

Jesper Hanno Hansen

After upgrading to 9.411-3 IOS devices cannot connect via IPSec, if the configuration on the ISO device is deleted and configured again via remote access it works, but we dont like to bother our users reinstalling the VPN configuration... is there a way out here?

 

Regards

Jesper Hanno



This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to Jesper Hanno Hansen

    Hi, Jesper, and welcome to the UTM Community!

    Sachin's suggestion is the correct one.  Go to the 'Management' section, and you will see that you can review the changes made since the Up2Date.  That will allow you to easily repeat the changes if needed.

    Before you restore the backup made just prior to the Up2Date, make another configuration backup.  If the restore "trick" doesn't solve your problem, just restore the newest backup.

    Cheers - Bob

Children
  • 0 in reply to BAlfson

    @Sachin's @BAlfson

    What is this restore backup thing?

    This is stupid. I have never restored a backup after an upgrade and it was never needed or useful. (In 15 Years Astaro/Sophos UTM)

     

    You only need the backup when HW is completly down or upgrade or rebuild.

     

    May

  • 0 in reply to BAlfson

    Thanks Bob, 

     

    Are there any other options, are there changes in the latest update to IPSec VPN that could justify this behaviour. we would prefer to know whats going on if thats an option...

    I tried to look at the syslog files, and on a device that having the problem we have

    Facility: authpriv
    Priority: warning
    Tag: 2017:02:15-16:15:46 remote pluto[6267]
    Message: "D_REF_IpsRoaForActivDirec_AaaUsexxxxxxx"[41] x.x.x.x:9853 #68: no suitable connection for peer 'C=xx, L=xxx, O=xxxxxx, CN=xxxxx, E=xxxxxxx@xxxxx.xx'

    Regards

    Jesper Hanno

  • 0 in reply to Jesper Hanno Hansen
    Extra lines from the log: "D_REF_IpsRoaForActivDirec_AaaUsexxxxxxx"[41] x.x.x.x:9853 #68: no suitable connection for peer 'C=xx, L=xxxxxx, O=xxxxxx, CN=xxxxxx, E=xxxxxx@xxxxxx.xx' "D_REF_IpsRoaForActivDirec_AaaUsexxxxxxx"[41] x.x.x.x:9853 #68: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:9853 packet from x.x.x.x:9853: ISAKMP version of ISAKMP Message has an unknown value: 80 packet from x.x.x.x:9853: sending notification INVALID_MAJOR_VERSION to x.x.x.x:9853 packet from x.x.x.x:9853: ISAKMP version of ISAKMP Message has an unknown value: 80 packet from x.x.x.x:9853: sending notification INVALID_MAJOR_VERSION to x.x.x.x:9853
  • 0 in reply to Jesper Hanno Hansen

    Delete the IPsec Connection and the Remote Gateway it uses, Jesper, and then create them both anew.  Any luck with that?

    If the restore "trick" doesn't help and this doesn't either, Support may tell you to re-image from ISO.  You should get a case open with them ASAP.

    It sounds like this device is mission-critical enough that you should be running a Hot-Standby.

    Cheers - Bob

  • 0 in reply to maygyver

    Hi Mygyver,

    In the most rear of cases, we discovered that restoring backup resolved the issue which was caused due to some minor backend changes after a firmware upgrade. 

    It is a basic step which I would recommend to follow after a firmware upgrade in the v9. Once verified, we can get into the depth to troubleshoot the issue.

    Cheers

  • 0 in reply to sachingurung

    Hi sachingurung ,

    I have never heard about it in 15 years UTM. I think it is a bad idea to always recommend this after an minor update. (9.408 to 9.409)

    It might be a good idea for a major update (9.3 to 9.4) or an Upgrade from (9 to 10). But even there it should not be the first thing to do. 

    The software must not have problems with minor backend changes.

     

    May

  • 0 in reply to BAlfson

    Let me try again..

    It is all the Apple IOS Devices that have this problem, if we delete the configuration on the Apple IOS device and logging in the the portal and reconfigure the client it works, but we are not happy about informing all users to recreate their VPN again...

    Regards

    Jesper Hanno

  • 0 in reply to Jesper Hanno Hansen

    Is this  a problem with all iOS devices? Which version? 

    I had several iOS VPN Problems, and they are an apple Problem, because they changed something.

    How old are these iOS VPN installations, how old is your UTM installation. May be your VPN CA Certificate has an old MD5.

     

    May

  • 0 in reply to maygyver

    It seems like it all IOS devices, we have not found any that did work, and the Apple IOS device version is 10.2.1 (the latest)

    The VPN installation/configuration is from October 15-20th 2016

     

    Regards

    Jesper Hanno

  • 0 in reply to maygyver

    Not after every Up2Date, May, just in cases where a problem appears mysteriously after an Up2Date.  I recommend a three-step process before re-imaging from ISO:

    1. The restore trick above.
    2. Reboot.
    3. Delete and re-create the failing object(s).

    It seems that fewer that 1 in a thousand configurations get broken during an Up2Date that includes upgrading objects instead of just installing new rpms.

    Cheers - Bob