Problem with UTM 9 connection to Azure

Hi All,

We have UTM 9 and firmware version is 9.603-1.  We have established a VPN connection to Azure. We have already one other connection to our branch We could not find the reason but it starts to give duplicate message problems and then the connection is dropping with Azure.   It happend every 2-4 days. 

2019:07:10-15:18:45 utm pluto[6401]: "S_REF_IpsSitAzure_0" #397: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

2019:07:10-15:18:45 utm pluto[6401]: "S_REF_IpsSitAzure_0" #397: sending encrypted notification INVALID_MESSAGE_ID to 168.63.44.99:500

2019:07:10-15:18:45 utm pluto[6401]: "S_REF_IpsSitAzure_0" #397: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x02000000 (perhaps this is a duplicated packet) 2019:07:10-15:18:45 utm pluto[6401]: "S_REF_IpsSitAzure_0" #397: sending encrypted notification INVALID_MESSAGE_ID to *:500

If vpn is working , there is no error message and everthing is working fine.

We are using policy based routing and we have tried to connect with Route based policy with Azure we could not connect the Azure. Microsoft says that, Route based policies are much stable compared to policay based route.

Can somebody suggest some resolution for this ? Thanks in advance.

Sedat EU 

  • Hi  

    Did you find anything in the logs from Azure? Also, it will require more logs to analyze this issue. Can you please share logs starting a min or two before the issue happened? That will throw some more light at the issue.

  • Hi Sedat,

    Unfortunately, Route Based is not compatible with the UTM and there aren't any workarounds (as will also need IKEv2).

    It looks like you may have a misconfiguration in the key lifetimes, have you confirmed all the settings? If you want to post your config, that would be helpful.

    Emile

  • In reply to EmileBelcourt:

     

    and the logs, it starts with duplicate messages and after 1-2 minutes, it drops the session and needs to restart to reconnect or restart the connection.

     

    2019:07:07-05:05:32 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: responding to Main Mode

    2019:07:07-05:05:32 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Peer ID is ID_IPV4_ADDR: 'AzureWANIP'

    2019:07:07-05:05:32 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sent MR3, ISAKMP SA established

    2019:07:07-05:05:32 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: cannot respond to IPsec SA request because no connection is known for 192.168.0.0/16===LocalWANIP[LocalWANIP]...AzureWANIP[AzureWANIP]===10.4.0.0/16

    2019:07:07-05:05:32 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_ID_INFORMATION to AzureWANIP:500

    2019:07:07-05:05:33 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:05:33 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:05:34 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:05:34 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #139 {using isakmp#140}

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: sent QI2, IPsec SA established {ESP=>0x10b00906 <0x5a762f83}

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: message ignored because it contains an unexpected payload type (ISAKMP_NEXT_HASH)

    2019:07:07-05:05:35 utm pluto[6401]: "S_REF_IpsSitAzure_0" #141: sending encrypted notification INVALID_PAYLOAD_TYPE to AzureWANIP:500

    2019:07:07-05:05:37 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:05:37 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:05:44 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:05:44 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:05:59 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:05:59 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:06:14 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:06:14 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: received Delete SA payload: replace IPSEC State #141 in 10 seconds

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [RFC 3947]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [FRAGMENTATION]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [Vid-Initial-Contact]

    2019:07:07-05:06:29 utm pluto[6401]: packet from AzureWANIP:500: ignoring Vendor ID payload [IKE CGA version 1]

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: responding to Main Mode

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #140: received Delete SA payload: deleting ISAKMP State #140

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: Peer ID is ID_IPV4_ADDR: 'AzureWANIP'

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: sent MR3, ISAKMP SA established

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: cannot respond to IPsec SA request because no connection is known for 192.168.0.0/16===LocalWANIP[LocalWANIP]...AzureWANIP[AzureWANIP]===10.4.0.0/16

    2019:07:07-05:06:29 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: sending encrypted notification INVALID_ID_INFORMATION to AzureWANIP:500

    2019:07:07-05:06:30 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:06:30 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:06:31 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:06:31 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:06:34 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

    2019:07:07-05:06:34 utm pluto[6401]: "S_REF_IpsSitAzure_0" #142: sending encrypted notification INVALID_MESSAGE_ID to AzureWANIP:500

    2019:07:07-05:06:39 utm pluto[6401]: "S_REF_IpsSitAzure_0" #143: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #141 {using isakmp#142}

    2019:07:07-05:06:39 utm pluto[6401]: "S_REF_IpsSitAzure_0" #143: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

  • Hi Sedat and welcome to the UTM Community!

    Is the UTM behind a NAT?

    Cheers - Bob

  • In reply to BAlfson:

    Nope sophos is connecting directly to internet and the other side is Azure Virtual network gateway and policy based connection.

    Thanks

  • In reply to BAlfson:

    Nope sophos is connecting directly to internet and the other side is Azure Virtual network gateway and policy based connection.

    Thanks

  • In reply to Sedat EKSI:

    This could work.

    Just to be sure, i talked about this in context XG in this Thread.

    https://community.sophos.com/products/xg-firewall/f/vpn/113212/anyone-has-experience-on-vpn-ipsec-site-to-site-beetwen-xg-17-x-and-azure/405616

    Maybe this KBA needs a Update: https://community.sophos.com/kb/en-us/126995

     Could you take a look? 

  • In reply to LuCar Toni:

    HI All,

    Thanks for your all support. I want to say some important things as I think.

    1. The connection establishes and works for at least 2 days without problems. Minimum 3 days up to now. So key exchanges are working properly, maksimum 27000 seconds as you can see configuration screenshot

    2. Route based VPN is not supported by UTM as far as I know. It is not written in any official document, Actually ı could nıt find for reverse but we tried there was no log about error; UTM says it is going to connection after some trials like 20 as I guess it leaves the connection but there is no real explanation in which stage the the problem is.

    3. UTM is not listed in Microsoft supported VPN device list

    Sophos is very responsive, they are also taking care of case. Meanwhile Any support is welcome and thanks again

    Regards

    Sedat

  • In reply to Sedat EKSI:

    Lets take a step back.

    UTM does not support Route based VPN "on UTM site".

    Route based VPN and Policy Based VPN are techniques to route your VPN on your device. It has literally no impact on the other site of the VPN tunnel. 

    SO basically you could connect a Route based VPN gateway to a UTM (Policy Based) and it perfectly work. 

    It is important to understand, that the IPsec SAs has to build up, and the traffic will be routed. 

     

    Azure now, has some kind of limitation. 

    So basically if you want to use the Route Based VPN in Azure, you have to use IKEv2, which is not supported by UTM. So you have to use the Policy based VPN method on Azure site to build up a tunnel, because policy based supports IKEv1. 

     

    Route based VPN does not have only Advantages. You would create Interface for each Tunnel. 

    Take a look at the bigger deployments of Route based VPNs with X.000 Tunnels. 

  • In reply to LuCar Toni:

    Lucar you did very good help again. I see you are very active in everywherw.

    I did not want to say UTM does not support route baded vpn. I told in limitation about my case which I am trying to connect sophos and azure with basic vpn functionality.

    I eill search for x.000 tunnels , ı havrnt used for many years.

  • In reply to LuCar Toni:

    Hi Toni

    For me, getting IKEv2 support for Sophos UTM9 would really help us out but seeing traces on roadmaps of two years old and "planned" and not seeing anything concrete makes me doubt that it will still come. Sure it was stated again on a specific version but then there are rumours that it moves to next year (2020?). It's an issue for us right now and it might result in replacing our Sophos router. Not sure if we would still opt for the brand though if we proceed with that option.

    I've set up a policy based VPN connection between Azure and Sophos UTM9 (our office) but we also have other sites (Amazon, other offices) that need to connect to the same VNET on Azure in the end and thats now causing me trouble in terms of what the architecture should look like.

    The other sites can all use an Azure based VPN1 Gateway (Route based) type so our Sophos UTM9 is the only one that cannot leverage this option which means I have a need for at minimum two Virtual Networks since one VNET on Azure can only contain one Gateway.

    So I have VNET1 -> Policy Based Gateway, VNET2 -> VPN1 Route Based Gateway and VNET3 where my application resides.

    I cannot have bidirectional peering between them all. VNET peering on Azure only allows the use of one VNET that contains a gateway. 

    I cannot do VNET-to-VNET on the VNET where the Sophos UTM9 is connected to because the policy based Gateway on Azure allows only "one connection".

    If I use VNET peering on the VNET1 (between VNET1 and VNET3) then I cannot do VNET-to-VNET between VNET2 and VNET3 because the VNET peering gets in the way of setting up the VNET-to-VNET connectivity.

    A complete burden and a hassle to be honest. Replacing Sophos UTM9 by a device that can do IKEv2 would solve the above architectural challenge because then I can use one gateway and have VNET peering between that VNET and the VNET where my application resides.

    Best regards

    Tom

  • In reply to Sedat EKSI:

    I tried for the sake of trying to see what happens and I could see in the log files that IKEv2 is ignored thus "not supported" and the tunnel will never get established.

    The IPsec VPN log should point this out.

    Policy Based connection (Basic VPN Gateway) to Azure works fine but this gives us other architectural challenges having to connect multiple sites.

  • In reply to Tom Cenens:

    Hoi Tom and welcome to the UTM Community!

    I think I remember some Sophos employee comment that getting XG to do IKEv2 was more difficult than expected and resulted in postponing IKEv2 for the UTM.

    That said, XG does do IKEv2 and Sophos would let you "upgrade" your UTM to XG without losing any of the time on your remaining subscriptions.  You might take a look at that and ask Sophos Sales for a recommendation of a Partner that has strong experience in XG and UTM if you current reseller does not.

    Please let us know what you wind up doing.

    Cheers - Bob

  • In reply to BAlfson:

    Hi Bob

    Thanks for your welcome note and feedback.

    Well, the architecture I had in mind seems to be impossible due to restrictions that also exist on Azure in terms of networking so either I'll need another router or I need to leverage another route. Feedback I got from our Cloud Service Provider is that my thoughts are correct and that the architecture that I would need is currently not supported on Azure. That's unfortunate, as on Amazon AWS it would not be any problem at all.

    Since we do have an Amazon AWS environment which is connected to Azure already, Route Based, I was thinking that I might, for the time being, leverage that route instead and go from our office -> Amazon AWS -> Azure. We are the hosting / support party for the customer. I don't want to have the latency on customer side, their offices should ideally be branched directly to Azure, on our side it's less of a problem as long as we can do our work properly.

    By doing that I can avoid the need for two VNET's with different Virtual Network Gateways on Azure and have one hub VNET and one spoke VNET (for the moment) and use VNET peering there and keep on using our Sophus UTM9 router for the time being.

    This will most likely be an interim solution as it's not ideal either and I would like to be connected also directly, with a minimal amount of latency.

    Getting feedback from other SAP partners and customers, they seem to point me in the direction of Fortigate in terms of features/functions/management/security as being a preferred option for us. So far I was very happy with our Sophos UTM9 router, it was configured by a partner and the first couple of VPN tunnels were created together after which I could completely do everything on my own. It's not our core business (SAP is) so the fact that I can quickly pick it up, configure it, get it to work and go beyond "easy" configuration means something. So I don't know yet to be honest what we will do. I will look into our options in terms of replacing the router be it by another Sophos device or another brand.

    Best regards

    Tom

  • In reply to Tom Cenens:

    Hi All,

     

    We have solved the problem but actually we could not find how it is solved. :(

    We have open the case to Sophos and they look all the logs but as fas I know, they did not touch anything on Sophos and it works very well. After two - three weeks, even there is a VPN is up, communication is stopped between local and azure, we need to turn it off and on and everything is fine.

     

    For short, I want to say my thanks to Sophos they are very helpful and give very quick responses. It is great to see that. 

    Yes, UTM does not support Route based policies with Azure.

    I guess the most problematic part is, there are not enough logs exist in Azure side to track. You have to open every log in Sophos side to understand problem. 

     

    Thanks for all supporters