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.
  • 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

    I'm having similar problems, but with a Juniper JUNOS device on the other side. The Juniper SRX cluster has a few dozen VPN tunnels that are all using the same IKE and IPSEC config as the tunnel to the XG, but the tunnel to the XG won't reconnect after the initial IKE timeout value is reached (28800 seconds). So I get an e-mail every 8 hours that the VPN tunnel is down. I have yet to find a way to get it working. 

    A tunnel with near identical configuration between two XG devices seems to work fine, but swapping out the HA cluster of Junos devices at the datacenter isn't an option. 

     

    I've seen a lot of reference to enabling an advanced option of "enable probing of pre shared keys", but that option does not seem to exist in the XG menu. 

  • 0 in reply to Andrew Bergman

    Thanks Andrew,

    That actually helps quite a bit.  I've found that if I set that option in the "Advanced" section of the UTM's IPSEC settings, I can get the connection to re-establish, both on line failure and on XG reboot, provided I set the XG VPN settings to "DefaultBranchOffice" policy and the connection to "re-initiate".

    Now, to see if I can get this setup working behind a NAT-ed Router...  :)

  • 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!