Community discussions

MikroTik App
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

IKE2 tunnels timing out. SA expiring in 30 min.

Sat Apr 04, 2020 4:19 am

I've read a lot of pages with people talking about this, but none of the suggestions have worked. The tunnel connects fine, but after about 25 min the connection stops working and after 30 min I get "IPsec-SA expired before finishing rekey" in the logs.

The SA Typically has this:
Add Lifetime		00:24:11/00:30:14
The Client:
/ip ipsec proposal add name="MGMT-proposal" auth-algorithms="sha1" enc-algorithms="aes-256-cbc" lifetime="1d" pfs-group="none"
/ip ipsec profile add name="MGMT-profile" hash-algorithm="sha256" enc-algorithm="aes-256" dh-group="modp2048" lifetime="1d" nat-traversal=yes
/ip ipsec peer add name="MGMT-peer" address=$svmanAddress port=4501 profile="MGMT-profile" passive="no" exchange-mode="ike2"
/ip ipsec identity add peer="MGMT-peer" secret=$manSecret my-id="fqdn:$MyDomain"
/ip ipsec policy add peer="MGMT-peer" tunnel=yes src-address=$localLanAddress dst-address=$managementLan proposal="MGMT-proposal" place-before=1
The Server:
/ip ipsec proposal add enc-algorithms=aes-256-cbc lifetime=1d name="MGMT-proposal" pfs-group=modp2048
/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name="MGMT-profile"
/ip ipsec peer add exchange-mode=ike2 name="MGMT-peer" passive=yes profile=MCB send-initial-contact=no
/ip ipsec identity add comment=generic generate-policy=port-override peer="MGMT-peer" secret=$manSecret
 
matd
just joined
Posts: 5
Joined: Wed Jan 17, 2018 5:12 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Sun Apr 05, 2020 12:40 am

Hi,
30min is default SA lifetime on Mikrotik, then rekeying happens, which fail in your case.
On IPsec proposals you have not maching pfs-group settings on client&server (which is exactly relevant for rekeying).
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Sun Apr 05, 2020 2:04 am

I had them matching and still had the issue. When googling the issue I ran across other people with similar problems with the suggestion to set the pfs-group to none on the client.

Here is one such link:
viewtopic.php?t=125617

Honestly it makes no difference. The client sets their lifetime to the set time of 1d, but the server defaults to 30m no matter what is set.

Even when setting both sides to 30 min, the connection completely drops out from 24m-30m until its rekeyed.
 
matd
just joined
Posts: 5
Joined: Wed Jan 17, 2018 5:12 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Sun Apr 05, 2020 9:56 am

Test it with pfs-group="none" on both sites
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Sun Apr 05, 2020 8:26 pm

Set both sides to none, same thing. It's still set to expire in 30 min on the server side
 
sindy
Forum Guru
Forum Guru
Posts: 6660
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Mon Apr 06, 2020 10:30 pm

The pfs setting issue is normally related only to the Windows embedded VPN client (and there, none at Mikrotik side is the only possibility); for an IPsec tunnel between two Mikrotiks, any pfs choice common for both peers normally works.

So I can only speculate - if there is transparent routing between the two peers (no NAT on either side), but there is a firewall between them, and you have disabled the DPD functionality, it is possible that the UDP control session is silent throughout the lifetime of the SA, so when it comes to rekeying, the pinhole for the control session at the firewall is already closed (whilst the ESP protocol used by the SA itself gets through as the SA keeps carrying traffic). This explanation is only relevant if the SA renegotiation is started by the responder peer, as if the initial packet from the initiator is able to create the pinhole in the external firewall, the rekey request packet from the initiator must be as well.

You haven't stated your RouterOS versions, this may be an issue too. I have tens of IPsec connections, and in the past, there used to be a randomly appearing issue with rekeying in IKEv2 mode where the rekeying succeeded but resulted in different ephemeral keys at both ends so the recipient could not decipher the received transport packets, but this has been fixed at least a year ago.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Tue Apr 07, 2020 4:07 am

Thank you for the detailed response sindy. I don't understand ipsec quite well enough to figure this out myself, so I appreciate your help.

The setup is a little messy, but I'll try to explain it.

The "Server" Router is currently running v6.45.8 (It was running the latest, but I just downgraded it just in case it was a bug)
The "Client Routers, of which there are over a dozen are running v6.45.7.

The "Server" Router is behind another Router with udp ports forwarded from 501, 4501 (wan) to 500, 4500 (MikroTik).
The "Clients" are all also behind various routers and are setup to connect to port 4501 on the Server IP. I'm actually not sure how to use port 501(500) since there's only one place to enter a port number on the peer, or even if its needed. I read in another thread that Mikrotik is setup to use 4500 for everything using ikev2.
 
sindy
Forum Guru
Forum Guru
Posts: 6660
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Tue Apr 07, 2020 8:43 pm

The "Server" Router is behind another Router with udp ports forwarded from 501, 4501 (wan) to 500, 4500 (MikroTik).
Okay. Unless one of the intermediate routers has an extremely short timeout, my assumption that it's a firewall issue is likely wrong.

So before diving any deeper, please try one simple thing - run a ping with a 1 second periodicity through the tunnel as soon as the connection establishes, and let it run until the first SA expires; if in this case the rekeying succeeds, the intermediate firewalls are the cause, otherwise it must be something else. The result will be the basis for choice of the subsequent analytic steps. Also, once the initial pair of SAs is up, check whether the dst-address and src-address in the output of /ip ipsec installed-sa print are just IP addresses or whether the port number is also printed - this indicates whether UDP encapsulation is in use (if ports are printed, it should be the case) or the IPsec somehow managed to choose plain ESP (if only IP addresses are printed).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Tue Apr 07, 2020 9:38 pm

I'll have to test one from the very second it establishes, but looking at the "uptime" on "active peers" I tested 6 of them over 20min old and without exception all pings cut out anywhere from 24m 2s to 24m 30s. Looking at their SA's, their soft lifetimes all seem to be in the same range. So it's cutting out as soon as it passes the soft lifetime.

As far as the ip/ports for the SA's. Looking at one pair of SA's from the Server side:
Pair 1:
Src Address: Public ip of client
Port: 4500
Dst Address: Wan ip of server (which is the private ip given to it by the main router)
Port: 4500

Pair 2:
Src Address: Wan ip of server (which is the private ip given to it by the main router)
Port: 4500
Dst Address: Public ip of client
Port: 4500

Looking at the SA's from the Client side:
Pair 1:
Src Address: Public ip of client
Port: 4500
Dst Address: Public ip of server
Port: 4501

Pair 2:
Src Address: Public ip of server
Port: 4501
Dst Address: Public ip of client
Port: 4500

On several tunnels I've noticed that the client side port is 1024. These also cut off exactly after their soft lifetimes. But in all cases the port is printed as well when looking at /ip ipsec installed-sa print .

I should note that one the server side router which the server Mikrotik sits behind "udp" and "tcp" are forwarded from 4501 to 4500. There is no option for any other type of packet.
 
sindy
Forum Guru
Forum Guru
Posts: 6660
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Tue Apr 07, 2020 10:34 pm

I'll have to test one from the very second it establishes, but looking at the "uptime" on "active peers" I tested 6 of them over 20min old and without exception all pings cut out anywhere from 24m 2s to 24m 30s. Looking at their SA's, their soft lifetimes all seem to be in the same range. So it's cutting out as soon as it passes the soft lifetime.
OK, so you have already done that test. It's not necessary to do it right from the very start, because the transport packets and the control packets use the same UDP stream as the /ip ipsec installed-sa print has shown. And it also means that the firewall hypothesis is wrong, except if highly theoretically the firewall was IPsec aware and was handling the control session's packets and the transport packets within that single stream selectively.

I should note that one the server side router which the server Mikrotik sits behind "udp" and "tcp" are forwarded from 4501 to 4500. There is no option for any other type of packet.
Forwarding TCP is enough.

So after all, it does look like an IPsec issue within RouterOS. Before diving into analysis of logs, please make sure that you use the same (single and common for both peers!) value as the dh-group in the relevant /ip ipsec profile item and as pfs-group in the relevant /ip ipsec proposal item used at both ends, try again and report the result. I hazily remember @emils to explain that these two parameters were related. But still, having none as pfs-group at both ends should work as well.

Also, can you show your complete /ip ipsec export hide-sensitive from both the "server" and the "client"? Maybe there is some mistake in the dependencies (proposal<-policy(template<-policy group)<-identity->peer->profile)? Double-check that the hide-sensitive has hidden any pre-shared secrets if used, and feel free to edit domain names, my-id, remote-id values possibly identifying you, they are not important for the purpose. Same for the public IP address(es) of course.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Tue Apr 07, 2020 10:55 pm

Server:
# apr/07/2020 15:45:46 by RouterOS 6.45.8
# software id = 
#
# model = RB760iGS
# serial number =
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=MGMT
/ip ipsec peer
add exchange-mode=ike2 name=MGMT passive=yes profile=MGMT send-initial-contact=no
/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=MGMT pfs-group=modp2048
/ip ipsec identity
add comment=generic generate-policy=port-strict peer=MGMT
Client:
# apr/07/2020 15:44:14 by RouterOS 6.45.8
# software id = 
#
# model = RB760iGS
# serial number =
/ip ipsec profile
add dh-group=modp1024 enc-algorithm=aes-256 name=VPN-profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=MGMT-profile
/ip ipsec peer
add address=Censored/32 exchange-mode=ike2 local-address= Censored name=MGMT-peer port=4501 profile=MGMT-profile
add address= Censored/32 exchange-mode=aggressive local-address= Censored name=VPN-peer profile=VPN-profile
/ip ipsec proposal
add enc-algorithms=aes-256-cbc lifetime=1d name=VPN-proposal
add enc-algorithms=aes-256-cbc name=MGMT-proposal pfs-group=modp2048
/ip ipsec identity
add my-id=key-id:Censored peer=VPN-peer
add my-id=fqdn:Censored peer=MGMT-peer
/ip ipsec policy
add dst-address=10.39.26.248/30 peer=MGMT-peer proposal=MGMT-proposal sa-dst-address=Censored sa-src-address=Censored src-address=10.39.26.16/30 tunnel=yes
add dst-address=10.0.0.0/8 peer=VPN-peer proposal=VPN-proposal sa-dst-address=Censored sa-src-address=Censored src-address=10.39.26.16/30 tunnel=yes

Note: As you can see the client side also has another active VPN, you can ignore it, but I thought I should include it in case its relevant. That one connects to another place with a Fortigate Router and it works just fine. The tunnel I'm concerned with on the client side is "MGMT" not "VPN".
 
sindy
Forum Guru
Forum Guru
Posts: 6660
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.  [SOLVED]

Wed Apr 08, 2020 12:31 am

Yes, that's it.

On the client, you manually specify a policy linked to the peer, and in the policy, you specify the proposal. Everything OK.
However, on the server, the identity says generate-policy=port-strict. That's fine, but what's missing is a policy-template-group specification. Since it is missing, /ip ipsec policy group default is used when searching for a template to generate the actual policy; in that group, there is a single policy template, "from anything to anything", which refers to /ip ipsec proposal default. And that proposal has pfs-group=modp1024. So regardless whether you set the pfs-group in your "MGMT" proposals at both ends to none or to modp2048, it will always differ from the modp1024 set in the default proposal.

So to fix it, do the following at server side:
/ip ipsec policy group add name=MGMT
/ip ipsec policy add template=yes group=MGMT proposal=MGMT
/ip ipsec identity set [find peer=MGMT] policy-template-group=MGMT


As you can see, the namespaces of the various configuration subtrees are separate, so the proposal named MGMT is not automatically used for dynamically created policies for identities linked to peer named MGMT or to profile named MGMT.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Wed Apr 08, 2020 12:48 am

sindy... you are AMAZING! That fixed it.

Thank you SO much for walking through that with me so patiently! That solved it. And now I know why there's a groups option in ipsec that I always skipped over : )
 
sindy
Forum Guru
Forum Guru
Posts: 6660
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Wed Apr 08, 2020 8:53 am

That fixed it.
Perfect. Now as you've said you have seen other topics dealing with the same issue, can you still find them again? I was trying to find something, but have only found cases where Mikrotik was only at one end of the connection, so the solution there may be completely different (plus they are quite old and Mikrotik's IPsec has evolved quite a lot in past two years while I keep track about it).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
hapoo
just joined
Topic Author
Posts: 22
Joined: Wed Apr 24, 2019 1:35 am

Re: IKE2 tunnels timing out. SA expiring in 30 min.

Wed Apr 08, 2020 5:16 pm

Same here. All the ones I found with 30m timeout issues were RW installations so I don’t think it was two mikrotiks.

Who is online

Users browsing this forum: alfoketer and 237 guests