Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 13315 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 - max number of retransmissions

Toruk Makto

Hallo zusammen,

ohne an der Konfiguration Änderungen vorzunehmen, habe ich die letzten zwei tage einen Verbindungsabbruch vom site 2 site IPSec Tunnel ohne sich wiederzuherstellen.

In den Logs von gestern und heute sind mit folgende Punkte aufgefallen. 

2016:12:21-03:02:24 zmi2 pluto[866]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_IpsSitIpsecdusst2" address="xxx.2" local_net="xxxx.0/24" remote_net="xxxxx.0/24"
2016:12:21-03:02:24 zmi2 pluto[866]: DPD: Restarting connection "S_REF_IpsSitIpsecdusst2_1"
2016:12:21-03:02:24 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #82: initiating Main Mode
2016:12:21-03:15:35 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #82: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2016:12:21-03:15:35 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #82: starting keying attempt 2 of an unlimited number
2016:12:21-03:15:35 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #83: initiating Main Mode to replace #82
2016:12:21-03:28:47 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #83: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2016:12:21-03:28:47 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #83: starting keying attempt 3 of an unlimited number
2016:12:21-03:28:47 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #84: initiating Main Mode to replace #83
2016:12:21-03:41:58 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #84: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2016:12:21-03:41:58 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #84: starting keying attempt 4 of an unlimited number
2016:12:21-03:41:58 zmi2 pluto[866]: "S_REF_IpsSitIpsecdusst2_3" #85: initiating Main Mode to replace #84

2016:12:20-03:02:25 zmi2 pluto[2327]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_IpsSitIpsecdusst2" address="xxxx.2" local_net="xxxx.0/24" remote_net="xxxx.0/24"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #101: deleting state (STATE_MAIN_R3)
2016:12:20-03:02:25 zmi2 pluto[2327]: DPD: Restarting connection "S_REF_IpsSitIpsecdusst2_3"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_0": DPD: Terminating all SAs using this connection
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_0" #107: deleting state (STATE_QUICK_I2)
2016:12:20-03:02:25 zmi2 pluto[2327]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_IpsSitIpsecdusst2" address="xxxx.2" local_net="xxx.0/24" remote_net="xxx.0/24"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_0" #98: deleting state (STATE_MAIN_I4)
2016:12:20-03:02:25 zmi2 pluto[2327]: DPD: Restarting connection "S_REF_IpsSitIpsecdusst2_0"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_2": DPD: Terminating all SAs using this connection
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_2" #108: deleting state (STATE_QUICK_I2)
2016:12:20-03:02:25 zmi2 pluto[2327]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_IpsSitIpsecdusst2" address="xxxx.2" local_net="xxx0/24" remote_net="xxx.0/24"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_2" #104: deleting state (STATE_QUICK_I2)
2016:12:20-03:02:25 zmi2 pluto[2327]: DPD: Restarting connection "S_REF_IpsSitIpsecdusst2_2"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_1": DPD: Terminating all SAs using this connection
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_1" #109: deleting state (STATE_QUICK_I2)
2016:12:20-03:02:25 zmi2 pluto[2327]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ipsec" connection="REF_IpsSitIpsecdusst2" address="xxxx.2" local_net="xxx0/24" remote_net="xxx.0/24"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_1" #105: deleting state (STATE_QUICK_I2)
2016:12:20-03:02:25 zmi2 pluto[2327]: DPD: Restarting connection "S_REF_IpsSitIpsecdusst2_1"
2016:12:20-03:02:25 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #110: initiating Main Mode
2016:12:20-03:15:35 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #110: max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message
2016:12:20-03:15:35 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #110: starting keying attempt 2 of an unlimited number
2016:12:20-03:15:35 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #111: initiating Main Mode to replace #110
2016:12:20-03:28:46 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #111: max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message
2016:12:20-03:28:46 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #111: starting keying attempt 3 of an unlimited number
2016:12:20-03:28:46 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #112: initiating Main Mode to replace #111
2016:12:20-03:41:56 zmi2 pluto[2327]: "S_REF_IpsSitIpsecdusst2_3" #112: max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message


Fast exakt zur selben Zeit fangen die Probleme an. Danach wird im Abstand von 13 Minuten versucht den Tunnel vergebens aufzubauen.
Ich hoffe einer von euch kann mit den Logs mehr anfangen.


Indem ich den Tunnel über die Webadmin Oberfläche deaktiviere und aktiviere (und das mehrmals) wird der irgendwann Tunnel wieder aufgebaut.
Ein langfristige Lösung sieht anders aus, jemand eine Idee?



This thread was automatically locked due to age.
Parents
  • 0

    Heute wieder das selbe Problem, auffällig sind zwei Meldungen wenn ich den Tunnel starte.

    2016:12:22-07:14:00 xxxx2 pluto[22510]: ERROR: "S_IPSEC_dus-stg_3" #1: sendto on lag0 to xxxxxxxxx.54:500 failed in main_outI1. Errno 1: Operation not permitted

    2016:12:22-07:15:20 xxxx2 pluto[22510]: "S_IPSEC_dus-stg_3" #1: max number of retransmissions (2) reached STATE_MAIN_I3. Possible authentication failure: no acceptable response to our first encrypted message

  • 0 in reply to Toruk Makto

    Hallo Toruk,

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

    We really haven't seen enough contiguous lines to understand the problem, but the last one does give a hint.  I'll guess that a public IP has changed but that one side or the other has a hardcoded VPN ID.

    If that doesn't get you there, please insert pictures of the relevant configurations on both sides including of the IPsec Policy.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    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

    Hallo BAlfson,

    aus vielen Dank für deine Unterstützung. 

    Anbei noch ein paar Informationen zu unserem Netzwerk, ich hoffe es hilft dir weiter. Wir setzen auf bei den Seiten eine VPN-ID ein. Warum kann ich dir leider nicht sagen, es wurde damals von einem Dienstleister konfiguriert.


    Standort STG:
    WAN <-> UTM <-> Internes Netzwerk

    Hostname: stu.120xxx.org
    Dyndns: stg-xxx.dyndns.org

    VPN-Optionen für lokalen RSA-Schlüssel
    VPN-ID-Typ: Hostname
    VPN-ID: stu.120xxx.org

     

    Standort DUS:
    WAN <-> UTM01 <-> DMZ <-> UTM02 <-> Internet Netzwerk 

    UTM01:
    Hostname: xxx.dyndns.org
    Dyndns: xxx2.dyndns.org + xxx.dyndns.org

    UTM02: (verantwortlich für IPSec Tunnel)
    Hostname: xxx2.dyndns.org

    VPN-Optionen für lokalen RSA-Schlüssel
    VPN-ID-Typ: Hostname
    VPN-ID: fw01

     


    Konfiguration an der stu.120xxx.org (STG)

     

    Konfiguration an der xxx2.dyndns.org (DUS)

     

    Falls du weitere Informationen benötigst lassen es mich bitte Wissen. Das Problem herrscht weiterhin und das Update auf die neusten Versionen hat keine Abhilfe gebracht.

  • 0 in reply to Toruk Makto

    STG is configured to use RSA keys, but DUS appears to be using a PSK (Verteilter Schlüssel).  Also, "stg_vpn_network" is expected by the DUS Remote Gateway but is not included in the STG IPsec Connection.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    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

    Hallo BAlfson,

     

    BAlfson said:

    STG is configured to use RSA keys, but DUS appears to be using a PSK (Verteilter Schlüssel).  

    Woran erkennst du diesen Unterschied, ich bin alle Einstellungen nochmals durchgegangen und finde nicht die Settings um es zu ändern!?

     

    BAlfson said:

    Also, "stg_vpn_network" is expected by the DUS Remote Gateway but is not included in the STG IPsec Connection.

    stg_vpn_network (192.168.xxx.xxx) ist auf dem entfernten Gateway auf xxx2.dyndns.org (DUS) und an stu.120xxx.org (STG) in den IPSec Connection unter Lokale Netzwerke als Internal Network (192.168.xxx.xxx) hinterlegt. stg_vpn_network und Internal Network unterstützen somit die selben Netze (192.168.xxx.xxx). Ist das etwa auch falsch!?

     

    Kann es sein, dass die beiden 2 WAN Anschlüsse an UTM1 in DUS mit aktiviertem Uplink Ausgleich zu den Ausfällen führen kann?

    WAN <-> UTM01 <-> DMZ <-> UTM02 <-> Internet Netzwerk 

    Die IPSec VPN wird von UTM02 aufgebaut, könnte es durch den Uplink Ausgleich an UTM01 zu Problemen kommen?

  • 0 in reply to Toruk Makto
    BAlfson: "STG is configured to use RSA keys, but DUS appears to be using a PSK (Verteilter Schlüssel)."

    "Woran erkennst du diesen Unterschied, ich bin alle Einstellungen nochmals durchgegangen und finde nicht die Settings um es zu ändern!?"

    You're right, I was confused by the inclusion of the pictures of the 'RSA key" tab and by your description of the RSA key configuration in your first post.

    "stg_vpn_network und Internal Network unterstützen somit die selben Netze (192.168.xxx.xxx). Ist das etwa auch falsch!?"

    If these are just two different objects for the same network, then one of the two doesn't need to be in the configuration.  If the vpn object is used in Remote Access and it overlaps with "Internal (Network)," then, yes, that can cause problems.  I see that you've added "VPN Pool (SSL)" to the IPsec Connection.  If this is the default 10.242.2.0/24 in both locations, then that will cause problems - I would change it in DUS to 10.242.12.0/24.

    "Kann es sein, dass die beiden 2 WAN Anschlüsse an UTM1 in DUS mit aktiviertem Uplink Ausgleich zu den Ausfällen führen kann?"

    That shouldn't be a problem.  In a situation where I have two ISPs, I will usually make an Interface Group and use that for the 'Local Interface' in the IPsec Connection.  On the other side, I will use an Availability Group as the 'Gateway' in the Remote Gateway.  Note that the order must be the same in the Availability Group as in the Interface Group.

    "Possible authentication failure: no acceptable response to our first encrypted message" can only be caused by a few things:

    • 'Enable probing of preshared keys' on the 'Erweitert' tab in both locations - this may have been the issue the entire time if you've recently added a new PSK in Remote Access or another site-to-site connection.
    • Compare the "AES 256" IPsec Policies to confirm that they are identical.
    • If both of those are good, create a new PSK to replace the one currently in use.
    • I don't see how it would be anything related to the IP address as I first guessed.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to Toruk Makto
    BAlfson: "STG is configured to use RSA keys, but DUS appears to be using a PSK (Verteilter Schlüssel)."

    "Woran erkennst du diesen Unterschied, ich bin alle Einstellungen nochmals durchgegangen und finde nicht die Settings um es zu ändern!?"

    You're right, I was confused by the inclusion of the pictures of the 'RSA key" tab and by your description of the RSA key configuration in your first post.

    "stg_vpn_network und Internal Network unterstützen somit die selben Netze (192.168.xxx.xxx). Ist das etwa auch falsch!?"

    If these are just two different objects for the same network, then one of the two doesn't need to be in the configuration.  If the vpn object is used in Remote Access and it overlaps with "Internal (Network)," then, yes, that can cause problems.  I see that you've added "VPN Pool (SSL)" to the IPsec Connection.  If this is the default 10.242.2.0/24 in both locations, then that will cause problems - I would change it in DUS to 10.242.12.0/24.

    "Kann es sein, dass die beiden 2 WAN Anschlüsse an UTM1 in DUS mit aktiviertem Uplink Ausgleich zu den Ausfällen führen kann?"

    That shouldn't be a problem.  In a situation where I have two ISPs, I will usually make an Interface Group and use that for the 'Local Interface' in the IPsec Connection.  On the other side, I will use an Availability Group as the 'Gateway' in the Remote Gateway.  Note that the order must be the same in the Availability Group as in the Interface Group.

    "Possible authentication failure: no acceptable response to our first encrypted message" can only be caused by a few things:

    • 'Enable probing of preshared keys' on the 'Erweitert' tab in both locations - this may have been the issue the entire time if you've recently added a new PSK in Remote Access or another site-to-site connection.
    • Compare the "AES 256" IPsec Policies to confirm that they are identical.
    • If both of those are good, create a new PSK to replace the one currently in use.
    • I don't see how it would be anything related to the IP address as I first guessed.
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
No Data