Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 29 subscribers
  • Views 20457 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 UTM to XG does not reconnect automatically

Shaun Raven

Morning All,

I've setup an IPSEC VPN between a UTM installation and a XG installation.  Everything works fine once I press the "connect" circle on the VPN tab in XG, but if the line breaks, the connection will not re-establish unless I press the "connect" circle again.

In UTM, this process is easy and automatic - not so it seems in XG.  What do I need to set on the XG to get this to work?  I've tried setting "action on restart" to respond only and initiate, but no joy.  I've also made sure the policy I'm using has "action when peer unreachable" set to "reinitiate".

Can anyone point me in the right direction please?

Many thanks.



This thread was automatically locked due to age.
Parents
  • 0

    We have the same setup and I ended up setting the XG to respond and the UTM to initiate.  This configuration has been working perfectly for a year or so with XG v15 > v16.01.2 and UTM being kept up to date.  I haven't yet tried it with XG v16.05

    Cheers,

    Charles

  • 0 in reply to CMR

    Thanks Charles - I tried that, but no luck I'm afraid.  But I am using 16.05.0 rc-1 - maybe that's the problem...

  • 0 in reply to Shaun Raven

    HI Shaun, 

     Could you upgrade to 16.05 GA and check if this would sort out your issue with VPN .

  • 0 in reply to Aditya Patel

    Hi Aditya,

    I would, but I'm testing this in a virtual environment away from the Internet - is there a way to upgrade whilst being offline?

  • 0 in reply to Shaun Raven

    Shaun,

    in order to uplaod the XG (offline) download the proper gpg file from Community XG blog and then upload it under Backup & Firmware > Firmware.

  • +1 in reply to lferrara

    OK - for the record, here's what I found.

    The "Enable probing of pre-shared keys" was a red herring.  The culprit turned out to be a mixutre of the VPN policy used, and the "Action on VPN restart" setting.  I initially used "AES128_MD5" as the policy and "respond only" as the action setting, as that's what was indicated by research into the documentation and forums.  This setup did indeed require UTM to have "enable probing of pre-shared keys" to be set for the VPN to re-establish.

    However, once I'd set the vpn policy to "DefaultBranchOffice" and the action setting to "initiate", I no longer needed to set "enable probing of pre-shared keys" on the UTM, and the VPN was able to reconnect fully automatically.  This setup worked on both versions of the firmware release tested.

    As a side note, this setup also worked behind a NAT router :) - Happy days!

     

Reply
  • +1 in reply to lferrara

    OK - for the record, here's what I found.

    The "Enable probing of pre-shared keys" was a red herring.  The culprit turned out to be a mixutre of the VPN policy used, and the "Action on VPN restart" setting.  I initially used "AES128_MD5" as the policy and "respond only" as the action setting, as that's what was indicated by research into the documentation and forums.  This setup did indeed require UTM to have "enable probing of pre-shared keys" to be set for the VPN to re-establish.

    However, once I'd set the vpn policy to "DefaultBranchOffice" and the action setting to "initiate", I no longer needed to set "enable probing of pre-shared keys" on the UTM, and the VPN was able to reconnect fully automatically.  This setup worked on both versions of the firmware release tested.

    As a side note, this setup also worked behind a NAT router :) - Happy days!

     

Children
No Data