IPsec IKEv2 GCP ping timeout

eset · Fri Apr 19, 2019 8:04 pm

I have a strange case which I thought I managed to resolve but I was wrong when again a working ipsec tunnel stopped working properly without any log information , anything.

Here is my config: https://gist.github.com/electropolis/d8 ... 461117eb7f

The problem is that clients behind MikroTik (VPN users) and other hosts in the same subnet where MikroTik is are losing connectivity with Servers on the other side of the tunnel (Google Cloud Platform). On CHR there is no evidence that something is wrong. I had issues with DPD on MikroTik that's why I've disabled that on MikroTik side after that I don't see any problems in Logs on both side. But once for a while in week there is a breakdown and suddenly, with no reason ping stops working , tunnel is working but all hosts are losing their connectivity.

From a server in network 10.128.0.0/10 to a server in the network 10.0.0.0/9

ping 10.5.0.120
PING 10.5.0.120 (10.5.0.120) 56(84) bytes of data.
PING 10.5.0.120 (10.5.0.120) 56(84) bytes of data.
--- 10.5.0.120 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1003ms

from Mikrotika CHR in that network 10.0.0.0/9 = to => 10.128.0.0/10

ping 10.156.0.10 src-address=10.5.0.120
SEQ HOST SIZE TTL TIME STATUS
0 10.156.0.10 timeout
1 10.156.0.10 timeout

Solution for that is to disable required entries in /ip ipsec policy to those networks and enabled them again to establish proper connection (picture below)

BGP peer are although still in established state:

IP route says:

I don't know what's happening and why it is happening.
RouterOS was 6.43.4 was because I've upgraded it Today to 6.43.14

lindagriffithh · Tue Jun 25, 2019 2:52 pm

I have a strange case which I thought I managed to resolve but I was wrong when again a working ipsec tunnel stopped working properly without any log information , anything.

Here is my config: https://gist.github.com/electropolis/d8 ... 461117eb7f

The problem is that clients behind MikroTik (VPN users) and other hosts in the same subnet where MikroTik is are losing connectivity with Servers on the other side of the tunnel (Google Cloud Platform). On CHR there is no evidence that something is wrong. I had issues with DPD on MikroTik that's why I've disabled that on MikroTik side after that I don't see any problems in Logs on both side. But once for a while in week there is a breakdown and suddenly, with no reason ping stops working , tunnel is working but all hosts are losing their connectivity.

From a server in network 10.128.0.0/10 to a server in the network 10.0.0.0/9
ping 10.5.0.120
PING 10.5.0.120 (10.5.0.120) 56(84) bytes of data.
PING 10.5.0.120 (10.5.0.120) 56(84) bytes of data.
--- 10.5.0.120 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1003ms
from Mikrotika CHR in that network 10.0.0.0/9 = to => 10.128.0.0/10
ping 10.156.0.10 src-address=10.5.0.120
SEQ HOST SIZE TTL TIME STATUS
0 10.156.0.10 timeout
1 10.156.0.10 timeout
Solution for that is to disable required entries in /ip ipsec policy to those networks and enabled them again to establish proper connection (picture below)

BGP peer are although still in established state:

IP route says:

I don't know what's happening and why it is happening.
RouterOS was 6.43.4 was because I've upgraded it Today to 6.43.14

Did you contact support? What you answered?
Maybe this is a problem with the server?

eset · Thu Jun 27, 2019 12:50 pm

Which Server? Google Cloud provide IaaS this a VPN service and it works normally. But it freeze sometimes and pings stops working at all. Now I have the same problem. I don't know what is happening.

eset · Thu Jul 25, 2019 11:41 am

I found in loogs from GCP VPN service that there is a
N(TEMP_FAIL)

When he establishe connection again after rekeying. I see someone has the same problem with Mikrotik connected to stronsgwan on Linux
https://wiki.strongswan.org/issues/2646

eset · Fri Oct 04, 2019 4:35 pm

Emil from MikroTik support is investigating this issue with me. But said also that , although, test release has this fix
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);

So it looks that Mikrotik has issues with rekeying.

eset · Tue Nov 12, 2019 5:21 pm

No one from mikrotik support will refer to this?

agungjies · Mon Nov 18, 2019 6:22 am

Emil from MikroTik support is investigating this issue with me. But said also that , although, test release has this fix
*) ike2 - fixed phase 1 rekeying (introduced in v6.45);

So it looks that Mikrotik has issues with rekeying.

I already see update on version 6.45.7

eset · Mon Dec 02, 2019 12:10 pm

Oh it's in stable now version. Hm So I need to wait for long-term to receive that update. But I'm not sure if that will resolve the problem
No problem isn't resolve. still the same issue occur

eset · Wed Jun 03, 2020 2:05 pm

After almost a year of digging ale looking for information. GCP Support helped. Mikrotik Support analyzed information from GCP Support and gave me also information which didn't satisfied me but there is nothing I can do right now so. More information here: viewtopic.php?f=2&t=161904&p=797600#p797600

IPsec IKEv2 GCP ping timeout [SOLVED]

IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout

Re: IPsec IKEv2 GCP ping timeout [SOLVED]

Who is online