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

Release of v17 MR-2?

Hej,

now that MR-1 has appeared, I wanted to ask when MR-2 will appear? The problems and instabilities of IPSec in v17 (especially in connection with V16.5) are very annoying.



This thread was automatically locked due to age.
  • Following the Big_bug alert on mr5 availiability i upgraded one of my sophos last night (i'm french)

    Everything seems to work normally, vpn are all connected and stable.. i will made more test simulating disconnetions asap to confirm but it seems to be better !

  • My first tests are very encouraging, vpn goes up after a pppoe disconnection or unexpected disconnection of peer that i simulate.

    But there is one thing that is still not solved : my wan interfaces are vlans connected to a switch, so its never physically goes down. in this case, VPN are never saw as disconneted, so it never goes up...

  • guillaume bottollier said:
    But there is one thing that is still not solved : my wan interfaces are vlans connected to a switch, so its never physically goes down. in this case, VPN are never saw as disconneted, so it never goes up...

    Hi guillame, i'd like to hear more details about that. Could you please contact me via Private Message, or send me an email.

  • ok, So loaded up MR-5 last night on my XG. After the XG rebooted (after it's update was complete), my vpn tunnel did not successfully come back up all the way. I still had some SA's that were red and the tunnel was not fully up.  Now to be fair,  this was right after the update was applied and perhaps it was busy doing other things, but that tunnel should of come up "clean and green" after the reboot.    So I had to manually disconnect and reconnect my tunnel after the reboot from the firmware upgrade.

     

    That being said, we're no longer seeing all those "Invalid SPI" error messages that we used to either.   So I've turned on debugging for strongswan in case the SA's dont re-establish themselves again.    

     

    We'll see what happens.

     

    -Scott

     

      

  • Thanks for sharing, I have a suspicion the IPSec VPN will be stable by MR 6.  I will definitely report my findings with MR 5 and test as IPSec VPN much as possible, but with all the issues reported it may just take a couple of updates to work everything out.  We are still waiting to hear how MR 5 does before considering updating any productions units to v17 from 16.5.

  • Totally not stable on MR6. I've been waiting and not touching mine that was on MR3 because somehow it was finally just working. Tunnel fell apart Monday and it's been a nightmare since trying to keep it holding traffic. 

    I did just make a change that I'm hoping will resolve it since the root issue is apparently having multiple child-sa's (according to some of the reports I've read here). I re-configured one of my subnets so that I could combine it with the other 3 in a /16 for my LAN instead of 4 /24's. Now there's just one /16 to /16 tunnel and I'm hoping it will work reliably. Supposed to head out traveling for 9 days and I'm the only one here that knows this @$^@$& firewall. Fingers crossed.

  • Still having issues with MR6 as well. Not even 2 Sophos XGs on MR6 are able to connect to each other with AES256 SHA256 etc. This is SUPER ANNOYING!!! Still got other tunnels to that just won't connect either for unknown reasons e.g. couldn't parse IKE message.

  • Personnaly, since 17.0.8 MR-8

    we have lot's of deconnection with peer VPN :

     

    2018-07-23 11:26:15 21[IKE] <Bailly_Courouble-1|4661> sending DPD request
    2018-07-23 11:26:15 21[ENC] <Bailly_Courouble-1|4661> generating INFORMATIONAL_V1 request 172699093 [ HASH N(DPD) ]
    2018-07-23 11:26:15 21[NET] <Bailly_Courouble-1|4661> sending packet: from XX.XX.XX.XX[500] to 185.39.XX.XX[500] (84 bytes)
    2018-07-23 11:26:15 31[NET] <Bailly_Courouble-1|4661> received packet: from 185.39.XX.XX[500] to XX.XX.XX.XX[500] (84 bytes)
    2018-07-23 11:26:15 31[ENC] <Bailly_Courouble-1|4661> parsed INFORMATIONAL_V1 request 2556777335 [ HASH N(DPD_ACK) ]
    2018-07-23 11:26:17 23[IKE] <Bailly_Courouble-1|4661> closing CHILD_SA Bailly_Courouble-4{112} with SPIs cb297606_i (1182675 bytes) 091159cd_o (770213 bytes) and TS 10.10.15.0/24 === 172.16.87.0/24
    2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [SSO] (sso_invoke_once) SSO is disabled.
    2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [COP-UPDOWN] (ref_counting) ref_count: 1 to 0 -- down -- (10.10.15.0/24#172.16.87.0/24)
    2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [COP-UPDOWN] (cop_updown_invoke_once) UID: 4661 Net: Local XX.XX.XX.XX Remote 185.39.XX.XX Connection: Bailly_Courouble Fullname:

  • Hello Bjoern

    We had a Cisco RV325 router between our XG210 and the internet ...  Sophos and Cisco were mutually allergic.  Cisco's RV325 very basic setup was 1 WAN address, and 8 LAN addresses.  That's it , that's all.  For some reasons, the RV325 was re forwarding back pings (Dead Peer Detection) from the XG210.  XG210 would consequently not see the other end and was dropping connections.  All this time, any other devices on our networks would ping each other.  WAN and LAN thru and outside the VPN.  In XG210's diagnostic menu, Firewalls WAN were pinging each other !!!  Go figure why DPD were bouncing.

    To make a long story short, Sophos support help me to put the WAN address directly into the Sophos XG210, allowing us to decommission the Cisco RV325.  He also helped me to setup the VoIP in such a way it would work with the WAN directly on the XG210.

    I may have to put back a router one day ...  What I'm gonna do then, I do not know ...

    On a positive note, latency felt from 60 ms in average down to 40 ms ...

    Paul Jr