Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 3619 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

IPSec Site to Site VPN Sophos UTM to SecurePoint not working

Dominik Wagner

Hey everybody,

I'm trying to setup an IPSec Site to Site VPN tunnel from our local Sophos UTM running firmware 9.700-5 to their SecurePoint firewall.

Here are some screenshots of the configuration on our end:

Here are some screenshots illustrating their end of the tunnel:

The log file on their end seems to suggest that the tunnel is coming up:

 

On our end however, I'm constantly receiving this error message:

2020:01:08-11:18:44 astaro pluto[7419]: "S_OTLG" #16: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:500
2020:01:08-11:18:54 astaro pluto[7419]: "S_OTLG" #1: ignoring informational payload, type PAYLOAD_MALFORMED
2020:01:08-11:19:14 astaro pluto[7419]: "S_OTLG" #1: ignoring informational payload, type INVALID_HASH_INFORMATION
 
Here's a screenshot of the log file:
 
It seems like the UTM has some problem with the ID of the remote firewall and subsequently fails to bring up the tunnel.
I am unsure however why this is the case.
 
Perhaps somebody in here has some kind of idea?
 
Thanks in advance,
Dominik


This thread was automatically locked due to age.
  • 0

    Seems to be invalid VPN ID informations...

    Check this on both sides! Some gateways use hostname instead of IP Adresses for VPN ID or if a gateway is behind another router and so there is a subnet between vpn-gateway and Router the VPN ID will be wrong because you have a private IP (IP of the local UTM WAN interface) instead of a public IP (if you have a direct WAN connection).

     

    VPN ID Sophos is here:

    regards

  • 0 in reply to Steve Weißflog

    Thanks for answering!

    I went ahead and set our VPN ID as our external IP adress in our UTM.

    I'll check back with my colleague on the other side and ask him to do the same.

    I'll let you know if it helps.

  • 0 in reply to Dominik Wagner

    Okay, I figured it out...it was all my fault, as usual :-)

    Under "Remote Gateway" - "Remote Networks" I had defined the entire /24 subnet of the customer.

    I had to add the 5 hosts from the client side as "Remote Networks" and voila, suddenly the tunnel came up.

    So chalk this one up to me not reading the original document properly documenting which hosts where reachable via this IPSec tunnel.

     

Unfiltered HTML