Hello,
i didnt expect that i will met issues with mikrotik but its look like that the new versions have some additional configs related to IPsec.
Here is my config on both sites.

##### SITE A ################
/ip ipsec profile
add name=ph1 proposal-check=strict
/ip ipsec peer
add address=PEER_IP1 local-address=192.168.1.1 name=1_rb profile=ph1 send-initial-contact=no
/ip ipsec proposal
add name=ph2
/ip ipsec identity
add my-id=address:192.168.1.1 peer=1_rb secret=12345678
/ip ipsec policy
add dst-address=192.168.10.0/24 proposal=ph2 src-address=10.200.10.0/24 tunnel=yes peer=1_rb
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.10.0/24 src-address=10.200.10.0/24

##### SITE B #################

/ip ipsec profile
add name=ph1 proposal-check=strict
/ip ipsec peer
add address=PEER_IP2 local-address=192.168.0.1 name=2_rb profile=ph1 send-initial-contact=no
/ip ipsec proposal
add name=ph2
/ip ipsec identity
add my-id=address:192.168.0.1 peer=2_rb secret=12345678
/ip ipsec policy
add src-address=192.168.10.0/24 proposal=ph2 dst-address=10.200.10.0/24 tunnel=yes peer=2_rb
/ip firewall nat
add action=accept chain=srcnat src-address=192.168.10.0/24 dst-address=10.200.10.0/24



factory-firmware: 6.44.5
current-firmware: 6.44.5
upgrade-firmware: 6.46.6

Ports UDP 500 and 4500 are open on both sites.
Does someone knows what is the issue?
The only thing that i see in ip firewall connection pr is that the ip try to establish connection but the state is not established.

Are they both behind NAT ?
If yes, it will not work...

Yes , both of them are behind NAT.
If its not possible if i downgrade the packages is it possible to establish IPsec in the same situation (again behind NAT)

Make sure only one will be behind NAT and make sure under /ip ipsec peer passive is enabled fo the RB that is not behind NAT...
The other RB must have send-initial-contact to yes

yep, understand . RB takes the passive=yes as a server mode which should wait for all clients connection. But i will keep testing beccause we are planing to terminate these devices in DC behind NAT and it have to work.
Now im worried .

If you can set up port forwarding in the DC (what comes to UDP port 4500 on the public IP will be forwarded to the inside address of the Mikrotik configured with passive=yes), you don't need to worry, it will work with IKEv2 (for IKE(v1), you would need to forward also UDP port 500).

Both sides are behind NAT and ports 500 and 4500 are forwarded to the routers on both sides.
I didnt test ikev2 but will try.
Your reply gave me some hope , thanks.
As additional information i see only attempt to establish connection in ip firewall connection print .

Have you enabled IPsec logging (/system logging add topics=ipsec,!packet)? If yes, can you see something in the log when the remote peer tries to connect? If ipsec logging is enabled but the log shows no IPsec connection attempts, post the config export, anonymised according to the hint in my automatic signature below.

it will work with IKEv2 (for IKE(v1), you would need to forward also UDP port 500).

@sindy could you remind me why this happens ?

it will work with IKEv2 (for IKE(v1), you would need to forward also UDP port 500).

@sindy could you remind me why this happens ?

An IKE(v1) responder listens at port 500; if the NAT-T extension is active at both peers and detects at least one of the peers to be behind a NAT, the information exchange moves to port 4500 at some later step. So both ports need to be accessible from outside at the responder side.

An IKEv2 responder must accept incoming connections at 4500 straight away, so RouterOS acting as an initiator does exactly that, hence there is no need to forward port 500 if the initiator is a Mikrotik. Other initiators (e.g. the Micrososft Windows embedded VPN client) send their initial packets to responder's port 500 even in IKEv2 mode, but I've understood the OP to use Tiks at both ends.

ESP need not be forwarded as if there is NAT at at least one end, it cannot be used.

ESP need not be forwarded as if there is NAT at at least one end, it cannot be used.

Isn't ESP encapsulated inside the UDP packet ?

ESP need not be forwarded as if there is NAT at at least one end, it cannot be used.

Isn't ESP encapsulated inside the UDP packet ?

Encapsulation of ESP into UDP is the way to deal with the NAT, the price to pay is less payload bytes per packet with a given MTU. If there is no NAT in either direction between the peers, they send bare ESP to each other.

ok @sindy thanks for reminding me

########### SITE1
/ip ipsec policy group
add name=test
/ip ipsec profile
add name=ph1
/ip ipsec peer
add address=IP2/32 exchange-mode=ike2 name=rb1 profile=ph1
/ip ipsec proposal
add name=ph2
/ip ipsec identity
add my-id=fqdn:second.internal peer=rb1 policy-template-group=test remote-id=fqdn:first.internal secret=12345678
/ip ipsec policy
add dst-address=10.100.100.0/24 level=unique peer=rb1 sa-dst-address=IP2/32 sa-src-address=192.168.0.35 src-address=192.168.50.0/24 tunnel=yes
set 1 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
/ip firewall nat
add action=accept chain=srcnat src-address=192.168.50.0/24 dst-address=10.100.100.0/24

ip ipsec policy pr
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 I rb1 yes 192.168.50.0/24 10.100.100.0/24 all encrypt unique 0




######### SITE2
/ip ipsec mode-config
add address-pool=ipsec_pool name=ipsec_test
/ip ipsec profile
add name=ph1
/ip ipsec peer
add address=IP1/32 exchange-mode=ike2 name=rb2 passive=yes profile=ph1 send-initial-contact=no
/ip ipsec proposal
add name=ph2
/ip ipsec identity
add my-id=fqdn:first.internal peer=rb2 remote-id=fqdn:second.internal secret=12345678
/ip ipsec policy
add dst-address=192.168.50.0/24 level=unique peer=rb2 sa-dst-address=IP1/32 sa-src-address=192.168.1.10 src-address=10.100.100.0/24 tunnel=yes

/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.50.0/24 src-address=10.100.100.0/24

ip ipsec policy pr
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 I rb2 yes 10.100.100.0/24 192.168.50.0/24 all encrypt unique 0


ip ipsec active-peers pr
lags: R - responder, N - natt-peer
# ID STATE UPTIME PH2-TOTAL REMOTE-ADDRESS DYNAMIC-ADDRESS
0 RN second.internal established 1h4m40s IP1/32


Now i have established phase1 but policies on both sides on are inactive .
Any suggestions ?

As you have specified the peer in the policies, there is no need to set sa-src-address and sa-dst-address, so set them to 0.0.0.0, maybe there is a conflict, the feature of automatic linking of the policy's addresses to peer's addresses is quite new. If that does not help, disable the initiator peer, do /system logging add topics=ipsec,!packet at both ends, run /log print follow-only file=ipsec-start where topics~"ipsec" at both ends, enable the initiator peer and let it run for a minute. Then stop the /log print at both ends and start reading the results.

Other than that, you've defined proposals named ph2, but you don't set them in the policies, so the policies use the default proposal (which is the same like the ph2 one). You have also specified a policy template group in the identity at one end but generate-policy is set to no; this causes no harm as you use statically configured policies, but it is useless.

Hi,
13:21:06 ipsec searching for policy for selector: PEER_IP1 <=> 192.168.0.35
ipsec no template matches
13:21:52 ipsec,error no policy found/generated


There is some issue with the policies.Because this router use private IP through which try to establish ipsec connection to PEER_IP1.
Could you give me example how should looks both sides if they use this ips

##### SITE1
PUBLIC_IP_ON_ANOTHER_ROUTER1 with forwards from 500,4500 to 500,4500
|
LOCAL_IP_WAN1 - MIKROTIK_WAN 192.168.1.1/24
|
LOCAL_LAN - MIKROTIK_LAN 192.168.88.1/24


##### SITE2

PUBLIC_IP_ON_ANOTHER_ROUTER2 with forwards from 500,4500 to 500,4500
|
LOCAL_IP_WAN2 - MIKROTIK_WAN 192.168.2.1/24
|
LOCAL_LAN - MIKROTIK_LAN 192.168.89.1/24

This "no policy template found" error comes after you have changed the configuration as I have suggested?

If so, post the output of /ip ipsec export hide-sensitive verbose from both machines. I can't see why it should need to generate a policy from template given that both policies are configured manually.

Its because both RB are behind NAT.
Try to find policy which match private_wan1_address of RB1 to REMOTE_PUBLIC_IP.

HERE is the CONFIG :

/ip ipsec policy group
add name=test
/ip ipsec profile
add name=ph1
/ip ipsec peer
add address=PEER2/32 exchange-mode=ike2 name=alex_rb profile=ph1
/ip ipsec proposal
add name=ph2 pfs-group=none
/ip ipsec identity
add generate-policy=port-strict my-id=fqdn:stoyan.internal peer=alex_rb policy-template-group=test remote-id=fqdn:alex.internal secret=12345678
/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
add dst-address=PEER2/32 group=test src-address=192.168.0.35/32 template=yes
add dst-address=10.100.100.0/24 group=test src-address=192.168.50.0/24 template=yes


/ip ipsec mode-config
add address-pool=ipsec_pool name=ipsec_test
/ip ipsec policy group
add name=test
/ip ipsec profile
add name=ph1
/ip ipsec peer
add address=PEER1/32 exchange-mode=ike2 name=stoyan_rb passive=yes profile=ph1 send-initial-contact=no
/ip ipsec proposal
add name=ph2 pfs-group=none
/ip ipsec identity
add generate-policy=port-strict my-id=fqdn:alex.internal peer=stoyan_rb policy-template-group=test remote-id=fqdn:stoyan.internal secret=12345678
/ip ipsec policy
set 0 group=test
add dst-address=PEER1/32 group=test src-address=192.168.0.35/32 template=yes
add dst-address=192.168.50.0/24 group=test src-address=10.100.100.0/24 template=yes



HERE iS THE LOG:

14:34:42 ipsec <- ike2 reply, exchange: INFORMATIONAL:14 PEER2[4500] 32de98ed5307dcc1:157879fd72c813dc
14:34:42 ipsec,debug ===== sending 156 bytes from 192.168.1.10[4500] to PEER2[4500]
14:34:42 ipsec,debug 1 times of 160 bytes message will be sent to PEER2[4500]
14:35:01 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:35:01 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:35:21 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:35:21 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:35:41 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:35:41 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:36:01 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:36:01 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:36:21 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:36:21 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:36:27 system,info route added by admin
14:36:38 system,info route removed by admin
14:36:41 ipsec,debug KA: 192.168.1.10[4500]->PEER2[4500]
14:36:41 ipsec,debug 1 times of 1 bytes message will be sent to PEER2[4500]
14:36:42 ipsec sending dpd packet
14:36:42 ipsec <- ike2 request, exchange: INFORMATIONAL:11 PEER2[4500] 32de98ed5307dcc1:157879fd72c813dc
14:36:42 ipsec,debug ===== sending 108 bytes from 192.168.1.10[4500] to PEER2[4500]
14:36:42 ipsec,debug 1 times of 112 bytes message will be sent to PEER2[4500]
14:36:42 ipsec,debug ===== received 140 bytes from PEER2[4500] to 192.168.1.10[4500]
14:36:42 ipsec -> ike2 request, exchange: INFORMATIONAL:15 PEER2[4500] 32de98ed5307dcc1:157879fd72c813dc
14:36:42 ipsec payload seen: ENC (112 bytes)
14:36:42 ipsec processing payload: ENC
14:36:42 ipsec,debug => iv (size 0x10)
14:36:42 ipsec,debug 31175c56 092b9eb9 ac33f565 5af8d931
14:36:42 ipsec,debug => plain payload (trimmed) (size 0x0)
14:36:42 ipsec,debug decrypted
14:36:42 ipsec dpd collision
14:36:42 ipsec <- ike2 reply, exchange: INFORMATIONAL:15 PEER2[4500] 32de98ed5307dcc1:157879fd72c813dc
14:36:42 ipsec,debug ===== sending 124 bytes from 192.168.1.10[4500] to PEER2[4500]
14:36:42 ipsec,debug 1 times of 128 bytes message will be sent to PEER2[4500]
14:36:42 ipsec,debug ===== received 156 bytes from PEER2[4500] to 192.168.1.10[4500]
14:36:42 ipsec -> ike2 reply, exchange: INFORMATIONAL:11 PEER2[4500] 32de98ed5307dcc1:157879fd72c813dc
14:36:42 ipsec payload seen: ENC (128 bytes)
14:36:42 ipsec processing payload: ENC
14:36:42 ipsec,debug => iv (size 0x10)
14:36:42 ipsec,debug b84cd039 c7c3f935 2b8cefd4 f65c6201
14:36:42 ipsec,debug => plain payload (trimmed) (size 0x0)
14:36:42 ipsec,debug decrypted
14:36:42 ipsec respond: info
14:36:42 ipsec,debug reply ignored

generate-policy other than no is used if the actual parameters of the policy depend on some changing input:

• one case used to be when the IP address of the remote peer was dynamic, but this should not be necessary ever since sa-dst-address became auto-generated (inherited) from the peer parameter if the peer parameter is specified for the policy,
• another case is when the remote peer is supposed to suggest its own policy autonomously (for whatever reason) and the local peer accommodates to that (if a wide enough policy template exists)
• yet another case is when the responder assigns an IP address to the initiator by means of mode-config; in that case, the policy needs to be generated at both the initiator and the responder, because in generic case, the address to be assigned to initiator is chosen from a pool at responder side.

But in your case here, it must be enough to set generate-policy at both ends to no, because you have manually configured the policies at both ends and nothing needs to be generated dynamically (actually, not even the sa-dst-address).