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

Azure IPsec VPN site-to-site drops constantly

Hello,

we have set an IPsec vpn site-to-site with Azure, the connection works fine all day but the problem is that my server on Azure has an auto-shutdown schedule that triggers at 11PM and after some minutes the server is turned off the VPN is terminated.

On the next day when the server is started the VPN won't connect automatically, and the odd thing is that on the Azure side it says it is connected and I have to connect it manually on the XG.

Have already disabled the re-key settings on the Azure IPSec Policy.



This thread was automatically locked due to age.
Parents Reply Children
  • VTI (or Route based VPN) is another way to deploy a IPsec Tunnel. It uses the routing stack and works better with Azure VPN Gateway.

    But XG105 and 85 are not eligible for V18, so you cannot move to VTI. 

    Those VPN Sessions are somewhat difficult to troubleshoot. Can you investigate the ipsec log to find the root cause of those flaps? 

  • Here are the logs when tunnel went down

    2020-09-14 23:24:20 26[NET] <VPNAzure-1|41> sending packet: from 192.168.15.2[4500] to 40.84.0.215[4500] (80 bytes)
    2020-09-14 23:24:22 30[NET] <VPNAzure-1|41> received packet: from 40.84.0.215[4500] to 192.168.15.2[4500] (80 bytes)
    2020-09-14 23:24:22 30[ENC] <VPNAzure-1|41> parsed INFORMATIONAL request 407 [ D ]
    2020-09-14 23:24:22 30[IKE] <VPNAzure-1|41> received DELETE for ESP CHILD_SA with SPI a811225a
    2020-09-14 23:24:22 30[IKE] <VPNAzure-1|41> closing CHILD_SA VPNAzure-1{14} with SPIs c818056f_i (19990222 bytes) a811225a_o (7114988 bytes) and TS 192.168.20.0/24 === 10.2.0.0/16
    2020-09-14 23:24:22 30[IKE] <VPNAzure-1|41> sending DELETE for ESP CHILD_SA with SPI c818056f
    2020-09-14 23:24:22 30[IKE] <VPNAzure-1|41> CHILD_SA closed
    2020-09-14 23:24:22 30[APP] <VPNAzure-1|41> [SSO] (sso_invoke_once) SSO is disabled.
    2020-09-14 23:24:22 30[APP] <VPNAzure-1|41> [COP-UPDOWN] (ref_counting) ref_count: 1 to 0 -- down -- (192.168.20.0/24#10.2.0.0/16)
    2020-09-14 23:24:22 30[APP] <VPNAzure-1|41> [COP-UPDOWN] (ref_counting_remote) ref_count_remote: 1 to 0 -- down -- (192.168.15.2#40.84.0.215)
    2020-09-14 23:24:22 30[APP] <VPNAzure-1|41> [COP-UPDOWN] (cop_updown_invoke_once) UID: 41 Net: Local 192.168.15.2 Remote 40.84.0.215 Connection: VPNAzure Fullname: VPNAzure-1
    2020-09-14 23:24:22 30[APP] <VPNAzure-1|41> [COP-UPDOWN] (cop_updown_invoke_once) Tunnel: User '' Peer-IP '' my-IP '' down-client
    2020-09-14 23:24:22 30[ENC] <VPNAzure-1|41> generating INFORMATIONAL response 407 [ D ]
    2020-09-14 23:24:22 30[NET] <VPNAzure-1|41> sending packet: from 192.168.15.2[4500] to 40.84.0.215[4500] (80 bytes)
    2020-09-14 23:24:22 30[APP] [COP-UPDOWN][DB] (db_conn_info) hostname: 'VPNAzure' result --> id: '1', mode: 'ntn', tunnel_type: '0', subnet_family:'0'
    2020-09-14 23:24:22 30[APP] [COP-UPDOWN] (add_routes) no routes to del for VPNAzure on interface ipsec0
    2020-09-14 23:24:23 30[APP] [COP-UPDOWN][SHELL] (run_shell) '/bin/opcode set_timer_mail_updown -s nosync -t json -b '{"event":"down","conn":"VPNAzure","local_net":"192.168.20.0/24","remote_net":"10.2.0.0/16","reason":"0"}'': success 0
    2020-09-14 23:24:34 29[NET] <VPNAzure-1|41> received packet: from 40.84.0.215[4500] to 192.168.15.2[4500] (80 bytes)
    2020-09-14 23:24:34 29[ENC] <VPNAzure-1|41> parsed INFORMATIONAL request 408 [ ]
    2020-09-14 23:24:34 29[ENC] <VPNAzure-1|41> generating INFORMATIONAL response 408 [ ]
    2020-09-14 23:24:34 29[NET] <VPNAzure-1|41> sending packet: from 192.168.15.2[4500] to 40.84.0.215[4500] (80 bytes)
    2020-09-14 23:24:48 19[NET] <VPNAzure-1|41> received packet: from 40.84.0.215[4500] to 192.168.15.2[4500] (80 bytes)

  • I heard some Rumors, there is a problem within Azure with Policy based tunnels. Could you rebuild your tunnel with powershell instead of Azure GUI?