Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 28983 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

Azure Site to site unstable

MarkMurphy
I have gotten the firewall to connect to Azure and can connect to vm's just fine. however the connection resets ever few min and reconnects. the following is the logs when this reconnect occurs. I have setup policy according to what Microsoft has documented. any ideas from this log as to what may be going on? Using latest ver. of UTM


2014:06:02-19:52:48 edge pluto[25476]: "S_Azure" #12: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 
2014:06:02-19:52:48 edge pluto[25476]: "S_Azure" #12: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #12: received Delete SA payload: replace IPSEC State #13 in 10 seconds 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #12: received Delete SA payload: deleting ISAKMP State #12 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [RFC 3947] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [FRAGMENTATION] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [Vid-Initial-Contact] 
2014:06:02-19:53:03 edge pluto[25476]: packet from 23.96.51.217:500: ignoring Vendor ID payload [IKE CGA version 1] 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #14: responding to Main Mode 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #14: Peer ID is ID_IPV4_ADDR: '23.96.51.217' 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #14: sent MR3, ISAKMP SA established 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #14: cannot respond to IPsec SA request because no connection is known for 192.168.21.0/24===69.14.191.53[69.14.191.53]...23.96.51.217[23.96.51.217]===192.168.50.0/24 
2014:06:02-19:53:03 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_ID_INFORMATION to 23.96.51.217:500 
2014:06:02-19:53:04 edge pluto[25476]: "S_Azure" #14: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 
2014:06:02-19:53:04 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
2014:06:02-19:53:05 edge pluto[25476]: "S_Azure" #14: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 
2014:06:02-19:53:05 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
2014:06:02-19:53:08 edge pluto[25476]: "S_Azure" #14: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 
2014:06:02-19:53:08 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
2014:06:02-19:53:13 edge pluto[25476]: "S_Azure" #15: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #13 {using isakmp#14} 
2014:06:02-19:53:13 edge pluto[25476]: "S_Azure" #15: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag 
2014:06:02-19:53:13 edge pluto[25476]: "S_Azure" #15: sent QI2, IPsec SA established {ESP=>0x98ba8372 


This thread was automatically locked due to age.
  • 0
    How does your configuration compare to Successful Site-to-Site VPN from UTM to Microsoft Azure and the post that follows it?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    I used that to get it working, The issue is that it is up and is stable for about 1 hour then I start getting these messages and the link seems to reset as I get a few pings lost then up again. This is what starts that cycle. Seems an issue with the 2nd phase for IPsec. I am using 9.201.23



    2014:06:02-19:53:04 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
     2014:06:02-19:53:05 edge pluto[25476]: "S_Azure" #14: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet) 
     2014:06:02-19:53:05 edge pluto[25476]: "S_Azure" #14: sending encrypted notification INVALID_MESSAGE_ID to 23.96.51.217:500 
     2014:06:02-19:53:08 edge pluto[25476]: "S_Azure" #14: Quick Mode I1 message is unacceptable because it uses a previously used Message ID
  • 0
    In About VPN Devices for Virtual Network, I found that your Policy's IKE SA Lifetime should be 28,800.  Also, on the 'Advanced' tab, Dead Peer detection isn't supported by Azure.  Any luck with those changes?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Thanks Bob, I seen that also and made those changes. As you can see the link stays stable for some time then starts to go south. If I restart the connection the cycle starts over. I wonder if there is an issue with this Ver of UTM at start of 13:13:24 the link stays stable until 14:44. then messages change and keep repeating.

    2014:06:03-13:13:24 edge pluto[5849]: "S_Azure" #146: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #145 {using isakmp#143} 
    2014:06:03-13:13:24 edge pluto[5849]: "S_Azure" #146: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag 
    2014:06:03-13:13:24 edge pluto[5849]: "S_Azure" #146: sent QI2, IPsec SA established {ESP=>0xf52d569e 0x170ea890 0xcc4faa52 0x01b840b2 0xb536bfb8 0x18a49546 0xe94c5494 0x061b652e 
  • 0
    At first, I thought it might be a timeout issue or DPD since you said the problem occurred after an hour (3600 seconds).

    Now, I don't think this is an IPsec issue, rather a hardware or layer-2 problem.  Do you have 'Support Path MTU discovery' selected in the Remote Gateway?  If that didn't fix this, then also try lowering the MTU on the Ethernet interface.  If that doesn't work, run ifconfig eth1 at the command line and consult #7 in Rulz.  Any luck?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    I found a feature request to have better (native even) support for Azure... since they are becoming more popular nowadays.  Look here:

    Native Microsoft Azure Site-to-Site VPN

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • +1
    Thanks for all the feed back and I did go vote for the feature request. So the issue I found was as follows

    In Azure I created a network of 192.168.50.0/24
    Then Azure created a subnet as 192.168.50.0/27 and I had do define a Gateway subnet as 192.168.50.32/29

    I defined in the remote gateway only the 192.168.50.0/27 and that was when I was getting all the errors and disconnects. 

    I went back to the remote gateway definition in UTM and changed that to 192.168.50.0/24 and the link is now useable and stable. I erroneously thought that since my VM's would only be on the /27 subnet that was why I defined in UTM the network I used for the remote gateway. This was what was causing the issues.

    Anyway all is well and link is sold now. Again thanks for all your feedback.
Unfiltered HTML