Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 37599 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

Site-to-Site IPSec VPN, keeps going down

MRoyland
Hi,

Having an issue where our Site-to-site IPSec connection to a subcontractors Zyxel keeps going down and we are unable on our end to restore the connection and rely on the subcontractor to restart the connection before it pops back up.

Log of the disconnect: 

       Line 2192: 2015:02:24-02:00:54 gw pluto[6164]: ""[12]  #18886: DPD: Could not find newest phase 1 state

       Line 2193: 2015:02:24-02:00:54 gw pluto[6164]: ""[12]  #18886: DPD: No response from peer - declaring peer dead

       Line 2194: 2015:02:24-02:00:54 gw pluto[6164]: ""[12]  #18886: DPD: Terminating all SAs using this connection

       Line 2195: 2015:02:24-02:00:54 gw pluto[6164]: ""[12]  #18886: deleting connection ""[12] instance with peer  {isakmp=#0/ipsec=#18886}



The other end tries endlessly to reconnect is unable to, log: 

       Line 2219: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1d00403]

       Line 2220: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: ignoring Vendor ID payload [afcad71368a1f1c96b8696fc7757]

       Line 2221: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]

       Line 2222: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

       Line 2223: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]

       Line 2224: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: received Vendor ID payload [RFC 3947]

       Line 2225: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: received Vendor ID payload [Dead Peer Detection]

       Line 2226: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: ignoring Vendor ID payload [afcad71368a1f1c96b8696fc7757]

       Line 2227: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22048]  #19358: responding to Main Mode from unknown peer 

       Line 2228: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22048]  #19358: NAT-Traversal: Result using RFC 3947: no NAT detected

       Line 2229: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22048]  #19358: next payload type of ISAKMP Identification Payload has an unknown value: 176

       Line 2230: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22048]  #19358: Preshared secret failed to decrypt message. Trying next one.

       Line 2231: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22048]  #19358: Peer ID is ID_FQDN: ''

       Line 2232: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22049]  #19358: deleting connection "L_REF_jUrNOUiCON_1"[22048] instance with peer  {isakmp=#0/ipsec=#0}

       Line 2233: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22049]  #19358: Dead Peer Detection (RFC 3706) enabled

       Line 2234: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22049]  #19358: sent MR3, ISAKMP SA established

       Line 2235: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22049]  #19358: ISAKMP SA expired (--dontrekey)

       Line 2236: 2015:02:24-02:01:47 gw pluto[6164]: "L_REF_jUrNOUiCON_1"[22049] : deleting connection "L_REF_jUrNOUiCON_1"[22049] instance with peer  {isakmp=#0/ipsec=#0}

       Line 2237: 2015:02:24-02:01:47 gw pluto[6164]: packet from :500: Informational Exchange is for an unknown (expired?) SA


Any ideas?


This thread was automatically locked due to age.
  • 0
    Hi, M, and welcome to the User BB!

    You didn't say what the time was from startup to failure - are the Lifetimes in your IPsec Policy aligned with the Zyxel?  Does the Zyxel also have DPD and NAT-T enabled?

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

    The time from start up to failure varies, but usually within a day or two. Lifetimes are aligned according to what has been agreed, DPD and NAT-T is enabled on the Zyxel (But their DPD does not detect that we have lost the connection) 

    This morning the connection restored it self, but it was down for about 12 hours, log of the reconnect: 

    2015:02:26-05:28:03 gw pluto[3971]: packet from :500: Informational Exchange is for an unknown (expired?) SA

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: ignoring Vendor ID payload [f758f22668750f03b08df6ebe1d00403]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: ignoring Vendor ID payload [afcad71368a1f1c96b8696fc7757]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: received Vendor ID payload [RFC 3947]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: received Vendor ID payload [Dead Peer Detection]

    2015:02:26-05:28:06 gw pluto[3971]: packet from :500: ignoring Vendor ID payload [afcad71368a1f1c96b8696fc7757]

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4029]  #2807: responding to Main Mode from unknown peer 

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4029]  #2807: NAT-Traversal: Result using RFC 3947: no NAT detected

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4029]  #2807: next payload type of ISAKMP Identification Payload has an unknown value: 121

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4029]  #2807: Preshared secret failed to decrypt message. Trying next one.

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4029]  #2807: Peer ID is ID_FQDN: ''

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4030]  #2807: deleting connection "S__0"[4029] instance with peer  {isakmp=#0/ipsec=#0}

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4030]  #2807: Dead Peer Detection (RFC 3706) enabled

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4030]  #2807: sent MR3, ISAKMP SA established

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4030]  #2808: responding to Quick Mode

    2015:02:26-05:28:06 gw pluto[3971]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="" address="" local_net="" remote_net=""

    2015:02:26-05:28:06 gw pluto[3971]: "S__0"[4030]  #2808: IPsec SA established {ESP=>0x495e1da5 _0"[4030]  #2807: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0x49171176) not found (maybe expired)

    2015:02:26-05:28:09 gw pluto[3971]: "S__0"[4030]  #2807: Informational Exchange message is invalid because it has a previously used Message ID (0x12c8e568)



    Also noticed something strange in the logs, the IP in question is unknown to both us and the subcontractor: 

    2015:02:26-05:29:59 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

    2015:02:26-05:30:39 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

    2015:02:26-05:31:19 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

    2015:02:26-05:31:59 gw pluto[3971]: "S__0"[152] : #2772: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message

    2015:02:26-05:31:59 gw pluto[3971]: "S__0"[152] : #2772: starting keying attempt 24 of an unlimited number

    2015:02:26-05:31:59 gw pluto[3971]: "S__0"[152] : #2812: initiating Main Mode to replace #2772

    2015:02:26-05:31:59 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

    2015:02:26-05:32:09 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

    2015:02:26-05:32:29 gw pluto[3971]: ERROR: asynchronous network error report on eth1 for message to  port , complainant : Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
  • 0
    If you already have 'Support Path MTU discovery' selected in the 'Advanced' section of the Remote Gateway, it's time to get help.  Someone needs to see more of the logs before they're obfuscated.  They also will want to see some IPsec logs from the Zyxel.

    I don't think the random IP is related to your issue, but it will be interesting to know what you learn.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    We did not have the Path MTU discovery option on, enabled it last week and waited to see if it had any effect. I did talk to our subcontractor, and their response was that they did not have a option for Path MTU discovery.

    I am starting to notice a pattern, I see that the link goes up at the same time of day no matter the time the link goes down. So I am starting to suspect that there is a a synchronization error between the Lifetimes.
    Eks. 
    Zyxel -> Sophos connection expires after x seconds, starting form time Y
    Sophos -> Zyxel connection expires after x seconds, starting from time Z

    Could this be a problem? Or do you suspect something else to be wrong?
  • 0
    If you want to continue to work on this here, please click on [Go Advanced] below and attach pictures of the following items open in Edit mode: IPsec Policy, Remote Gateway & IPsec Connection.  Also, pictures of the Zyxel IPsec configuration.

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

    Hi everybody,

     

    I would like to know if those logs comes from vyatta firewall logs?

     

    These logs are only about vpn?

     

    Otherwise where does those log come from?

     

    In case those logs come from vyattta firewall Is there a way to configure the firewall so that to obtain (in the logs) information about ip src, ip dst, mac, packet denied , packet permitted?

     

    Thank you very much!

     

    Xavier 

  • 0 in reply to Xdumas DUMAS

    Salut Xavier and welcome to the UTM Community!

    The log lines above are all from the UTM's IPsec log.

    In the UTM firewall, all packets will be dropped by default if they are not explicitly permitted by some setting or Firewall rule.  The information you asked for will be in the Firewall log for these packets.

    If you have explicit firewall rules that allow certain traffic, you can select to have these permitted packets logged and you will see the information you want.

    For traffic handled by proxies (HTTP/S, FTP, SMTP, etc.) the information will be in the corresponding log.

    Did that answer your questions?

    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

    Hi Bob,

     

    Thank you for this very helpful answer.

    Yes you answered perfectly to my questions.

     

    Thx again.

    Xavier.

Unfiltered HTML