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

What's the standard procedure for implementing a Policy based Ipsec Connection between Azure and Sophos UTM v9.601-5 ?

Hi,

 

The main purpose of this question is to filter and find the most recent and working solution for implementing a virtual network gateway between Azure ans Sophos UTM, because i have been following multiples guides with similar configuration and yet, i don't have any success so far.

Guides followed:

 

Currently, without much experience on Sophos UTM and following the first and second guide, i was able to have a connection working between our networks but the connection is always dropping, so my main question would be how could i find a more recent and working guide for setting up one or multiples gateways between azure and sophos UTM ?


Thanks in advance.

 



This thread was automatically locked due to age.
Parents
  • Bumping this one - having the exact same issue. Trying to setup an IPSEC Site to Site VPN between my On-Prem environment behind an SG230 and Microsoft Azure. Followed those latest guides to the letter and every suggestion I could find on these forums and all I am getting is:

    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: received Vendor ID payload [RFC 3947]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [FRAGMENTATION]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [Vid-Initial-Contact]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: ignoring Vendor ID payload [IKE CGA version 1]
    2019:05:02-10:47:42 FW-SG230 pluto[8360]: packet from x.x.x.x:500: initial Main Mode message received on x.x.x.x:500 but no connection has been authorized with policy=PSK
     
    Tried setting it to Respond Only (and changed the Azure end to match etc) and exactly the same messages. Tried playing with Policy settings other people have said worked for them in other threads here - same results. Tried Probing of Pre-Shared Keys. Tried enabling NAT Traversal. Just keep getting the same message: initial Main Mode message received on x.x.x.x:500 but no connection has been authorized with policy=PSK

    Any clues, tips or hints are greatly appreciated - as usual ;) 
  • If you followed https://community.sophos.com/kb/en-us/126995 exactly, it should work.  I would definitely select Probing and NAT-T and use an "Initiate connection" Remote Gateway.  You do have a public IP on the UTM - right?  Please show a picture of the Edit of the IPsec Policy you're using.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi,

     

    Currently we have a stable connection between azure  regardint http, https and ssh transfer, but also have a unstable RDP connection, which currently its terrible ( drops 1/2 times every 60 seconds ).

    Our current ipsec policy is the same provided on the guide:

     

     

    Regarding the public IP, yes, we have multiple connections across the globe, but currently, since we have some servers on azure, we are facing some issues regarding this matter

Reply
  • Hi,

     

    Currently we have a stable connection between azure  regardint http, https and ssh transfer, but also have a unstable RDP connection, which currently its terrible ( drops 1/2 times every 60 seconds ).

    Our current ipsec policy is the same provided on the guide:

     

     

    Regarding the public IP, yes, we have multiple connections across the globe, but currently, since we have some servers on azure, we are facing some issues regarding this matter

Children
No Data