Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 10422 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

Intermittent problems with IPsec site to site tunnel

krylon
Hello everyone,

We have a Sophos UTM 9 (9.307-6 as of this morning) at our headquarters and a branch office with a UTM 9 (9.306-6 - I haven't gotten around to installing the most recent update, yet), connected by an IPsec site to site tunnel.

Recently, this VPN connection has experienced intermittent connection failures, which gets the users in that branch office rather upset (not that I can blame them).

We have not made any changes to the VPN settings, but we have recently opened one new branch office and replaced the aging Draytek Vigor router in the other one, now both of these branch offices have Fritz!Boxes (a 7272 and a 7390, in case it matters).

I set up the IPsec tunnels to both of these branch offices myself, something I have never done before. Initially, both of these offices experienced intermittent connection failures (at the VPN level, the DSL lines were fine!). Today, I recreated the configuration files for the VPN tunnels for these offices from scratch and uploaded them to the Fritz!Boxes. Neither office has experienced any trouble today, which leads me to believe that I got it right this time.

But the first branch office, the one with the UTM 9, has experienced yet another failure of their VPN tunnel today. When Nagios notified me of the problem, I checked if could reach the UTM on its public IP address (this office does not have a static IP, AND their UTM sits behind an EasyBox provided by Vodafon, which has already been replaced once), pinged it, logged into the Web Interface, but when I had logged in, the connection was already working again.

I checked the IPsec log on the remote UTM, and found the following lines around the time of the connection failure: 

2015:02:04-13:03:57 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: responding to Main Mode
2015:02:04-13:03:57 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: NAT-Traversal: Result using RFC 3947: i am NATed
2015:02:04-13:03:57 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: next payload type of ISAKMP Identification Payload has an unknown value: 91
2015:02:04-13:03:57 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)
2015:02:04-13:03:57 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: sending encrypted notification PAYLOAD_MALFORMED to 62.153.71.106:4500
2015:02:04-13:04:07 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: next payload type of ISAKMP Identification Payload has an unknown value: 91
2015:02:04-13:04:07 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)
2015:02:04-13:04:07 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: sending encrypted notification PAYLOAD_MALFORMED to 62.153.71.106:4500
2015:02:04-13:04:27 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: next payload type of ISAKMP Identification Payload has an unknown value: 91
2015:02:04-13:04:27 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)
2015:02:04-13:04:27 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #494: sending encrypted notification PAYLOAD_MALFORMED to 62.153.71.106:4500

Oh yes, I forgot to mention: The connection is secured by preshared keys (PSK). Which I am told is kind of a bad idea, but it has been like that when I started working here, and I am kind of hesitant to change this now, unless someone can plausibly explain to me that it will make these connection issues go away.

Also, when I looked at the log a little longer, the above messages show up all the time.
The one thing that stood out the time of the connection failure is this:

2015:02:04-13:06:13 wellmann pluto[1625]: listening for IKE messages
2015:02:04-13:06:13 wellmann pluto[1625]: forgetting secrets
2015:02:04-13:06:13 wellmann pluto[1625]: loading secrets from "/etc/ipsec.secrets"
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded private key from 'REF_CaHosIphone.pem'
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded PSK secret for 192.168.2.100 10.20.30.40
2015:02:04-13:06:13 wellmann pluto[1625]: forgetting secrets
2015:02:04-13:06:13 wellmann pluto[1625]: loading secrets from "/etc/ipsec.secrets"
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded private key from 'REF_CaHosIphone.pem'
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded PSK secret for 192.168.2.100 10.20.30.40
2015:02:04-13:06:13 wellmann pluto[1625]: loading ca certificates from '/etc/ipsec.d/cacerts'
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu.pem'
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_UaZXRTYgfQ.pem'
2015:02:04-13:06:13 wellmann pluto[1625]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu2.pem'
2015:02:04-13:06:13 wellmann pluto[1625]: loading aa certificates from '/etc/ipsec.d/aacerts'
2015:02:04-13:06:13 wellmann pluto[1625]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2015:02:04-13:06:13 wellmann pluto[1625]: loading attribute certificates from '/etc/ipsec.d/acerts'
2015:02:04-13:06:13 wellmann pluto[1625]: Changing to directory '/etc/ipsec.d/crls'
2015:02:04-13:06:13 wellmann ipsec_starter[5945]: no default route - cannot cope with %defaultroute!!!
2015:02:04-13:06:13 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0": deleting connection
2015:02:04-13:06:13 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #495: deleting state (STATE_MAIN_R2)
2015:02:04-13:06:13 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #487: deleting state (STATE_QUICK_I2)
2015:02:04-13:06:13 wellmann pluto[1625]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_YWvtzADrXH" address="192.168.2.10" local_net="192.168.1.0/24" remote_net="192.168.80.0/24"
2015:02:04-13:06:13 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #447: deleting state (STATE_QUICK_I2)
2015:02:04-13:06:13 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #433: deleting state (STATE_MAIN_I4)
2015:02:04-13:06:14 wellmann pluto[1625]: added connection description "S_REF_YWvtzADrXH_0"
2015:02:04-13:06:14 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: initiating Main Mode
2015:02:04-13:06:14 wellmann pluto[1625]: ERROR: "S_REF_YWvtzADrXH_0" #496: sendto on eth3 to 10.20.30.40:500 failed in main_outI1. Errno 1: Operation not permitted
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: received Vendor ID payload [strongSwan]
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: ignoring Vendor ID payload [Cisco-Unity]
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: received Vendor ID payload [XAUTH]
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: received Vendor ID payload [Dead Peer Detection]
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: received Vendor ID payload [RFC 3947]
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: enabling possible NAT-traversal with method 3
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: NAT-Traversal: Result using RFC 3947: i am NATed
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: Peer ID is ID_IPV4_ADDR: '10.20.30.40'
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: Dead Peer Detection (RFC 3706) enabled
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #496: ISAKMP SA established
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #497: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#496}
2015:02:04-13:06:24 wellmann pluto[1625]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="REF_YWvtzADrXH" address="192.168.2.100" local_net="192.168.1.0/24" remote_net="192.168.80.0/24"
2015:02:04-13:06:24 wellmann pluto[1625]: "S_REF_YWvtzADrXH_0" #497: sent QI2, IPsec SA established {ESP=>0x0092a666 0x4cad06ec 


This thread was automatically locked due to age.
  • 0
    Benjamin, it looks like a configuration issue or flaky hardware.  Is the VPN connecting to a FritzBox or to the other UTM?  Are DPD and NAT-T selected on both sides?

    Please click on [Go Advanced] and attach pictures of both sides of the Remote Gateway and IPsec Connection open in Edit mode.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Thank you very much for your answer,

    Here the images, first from the UTM at our headquarters, then from the remote office:

    One thing I find peculiar when looking at these is that the Local Interface on the Astaro at our branch office is set to "Uplink Interfaces" - the office does have two VDSL lines. I am not sure if this could cause problems (but then again, what would be the point in even offering that option?).

    Kind regards,
    Benjamin
  • 0
    Do you have a Multipath rule for IPsec?  The easiest would be to have IPsec traffic use persistence by destination.

    If you want to know how to configure automatic failover for a VPN between two sites that each have two WAN connections, please open a new thread.

    Cheers - Bob
    PS Benjamin, I'm sorry, but I deleted the external links in your post.  Please [Edit] that post, click on [Go Advanced] and attach your images to the post.  We can't know if that external site is properly protected. The only malware I've gotten in over 10 years was from a link to a picture in this forum several years ago.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    PS Benjamin, I'm sorry, but I deleted the external links in your post.  Please [Edit] that post, click on [Go Advanced] and attach your images to the post.  We can't know if that external site is properly protected. The only malware I've gotten in over 10 years was from a link to a picture in this forum several years ago.


    I beg your pardon! I corrected that and attached the images.

    Multipath IPsec or failover is not on my todo-list right now. Both DSL lines in the remote office are from the same provider, so the chance is pretty high that if one of them fails, the other one will, too. I just need the existing VPN connection to work without any hickups so the users are happy.
  • 0
    No problem, you're new here.  Thanks!

    Did the Multipath Rule solve the problem?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    No problem, you're new here.  Thanks!

    Did the Multipath Rule solve the problem?

    Cheers - Bob


    I added the Multipath rule last weekend and had no complaints all week. So I think it solved the problem.

    Thank you very much for your help, and have a great weekend,
    Benjamin
Unfiltered HTML