none
Azure virtual network, site to site VPN, Fortigate 110c Firewall

    Question

  • Hi,

    After struggling and messing around with all sorts of settings my end, I've managed to get our local fortigate 110c firewall connected to Azure Virtual network using IPsec tunnel. The issue is its highly unstable and drops after 10-20 seconds, and takes a random amount of time to come back up.

    I'm seeing this error a lot on the fortigate:

    Received ESP packet with unknown SPI.

    Here is the full config:

    phase-1:

    Phase-2:

    Static routes are in place and firewall policies allow traffic both ways.

    Anyone have any experience with this is care to throw a guess as to why I'm getting such short connections? Also the connection doesn't come up on its own, I have to force it in the fortigate VPN monitor which is hit and miss.

    Wednesday, June 13, 2012 6:10 AM

Answers

  • Hi, Paul:

    This is awesome!  Thanks a lot for sharing with us. 

    As for the "replay detection" option, we have actually noticed this on some of the Juniper devices we supported (that is Juniper ISG or SSG devices).  If you look at our template configuration script for Juniper ISG or SSG, you will find the following line:

    set vpn <RP_IPSecVpn> gateway <RP_IkeGateway> tunnel idletime 0 proposal <RP_IPSecProposal>

    But once you enter this line into the device, and then do a "get config", it shows:

    set vpn <RP_IPSecVpn> gateway <RP_IkeGateway> no-replay tunnel idletime 0 proposal <RP_IPSecProposal>

    Notice the keyword "no-replay" there?  That's the default behavior on Juniper SSG or ISG devices.

    • Marked as answer by Arwind - MSFT Tuesday, June 19, 2012 10:08 AM
    Wednesday, June 13, 2012 6:51 PM

All replies

  • ok just a quick update, seems I may have sorted things but I'll keep monitoring....

    I made one change to the config above, although I'm sure I had tried it before I must have had something else enabled that was conflicting.

    The change is to 'enable replay detection' - that's it, stable for 1403 seconds! :)

    That's with file transfer, without and with pings both ways.

    Wednesday, June 13, 2012 6:36 AM
  • Hi, Paul:

    This is awesome!  Thanks a lot for sharing with us. 

    As for the "replay detection" option, we have actually noticed this on some of the Juniper devices we supported (that is Juniper ISG or SSG devices).  If you look at our template configuration script for Juniper ISG or SSG, you will find the following line:

    set vpn <RP_IPSecVpn> gateway <RP_IkeGateway> tunnel idletime 0 proposal <RP_IPSecProposal>

    But once you enter this line into the device, and then do a "get config", it shows:

    set vpn <RP_IPSecVpn> gateway <RP_IkeGateway> no-replay tunnel idletime 0 proposal <RP_IPSecProposal>

    Notice the keyword "no-replay" there?  That's the default behavior on Juniper SSG or ISG devices.

    • Marked as answer by Arwind - MSFT Tuesday, June 19, 2012 10:08 AM
    Wednesday, June 13, 2012 6:51 PM
  • We are having a similar problem with a FortiGate 200B, we have to "Bring Up" the connection mannually but it drops the link exactly 64 seconds later, without automatically brining it back up. We have tried multiple setting variations with no luck. When the link is up we can ping from an azure VM to our local network but not the other way around.

    Our config is as follows:

    Static Route: 172.16.0.0/16

    Local: 10.10.100.0/24

    Azure: 172.16.0.0/16


    ADTU Enterprises


    • Edited by adtuent Monday, July 23, 2012 12:19 AM
    Monday, July 23, 2012 12:18 AM
  • Hi

    I am a sysadmin for a software R&D company,  we will begin some implementing  a solution similar to this as part of a large scale QA experiment  . I have not begun any configurations yet as we are still in the planing stage. I'm really happy to have found this post because I was quite worried that I was alone in  what I am planing to attempt. 

    Can anyone one here confirm that trey were able to get a stable tunnel up and running that can be used in production over a prolonged period of time .

    Thanks

    Jonx

    Tuesday, July 31, 2012 3:04 PM
  • Sorry - first time posting and pressed the wrong "Propose As Answer Link".

    We've had a stable link for quite a few hours now and been transferring quite a bit of data during that time.

    While it's not the "prolonged period of time" that jonxm05 is asking for, we're certainly getting stable results that are lasting longer than the 65 seconds proposed above.

    Tuesday, August 14, 2012 2:17 AM
  • We were considering using a Fortigate 310B to create a site-to-site vpn tunnel ot Azure. I was hoping dealersolutions could provide an update on the reliability and performance of the thier Fortigate VPN.
    Thursday, April 25, 2013 6:42 PM
  • We use fortigate 100D and it is no problem to configrue site to site VPN.

    But the S2S link seems not very stable. I try to ping our intranet IP then some times show request tome out. 

    does anyone know how to fix this problem?

    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=87ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=87ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=90ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=88ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=87ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=86ms TTL=254
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
    Reply from 192.168.230.1: bytes=32 time=87ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=85ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=88ms TTL=254
    Reply from 192.168.230.1: bytes=32 time=87ms TTL=254

    Friday, August 01, 2014 9:03 AM