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.
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.
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.
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.
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.
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.
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).
