Hello! Having troubles to setup my Mikrotik (RB750GL with 6.47.1) to establish a IPsec IKEv2 VPN with a Cisco router. Here’s the config of the Cisco Router that was sent to me:
crypto ikev2 proposal ikev2-prop-partner
encryption aes-gcm-256
prf sha512
group 14
crypto ikev2 policy ikev2-policy-partner
match fvrf any
proposal ikev2-prop-partner
crypto ikev2 keyring ikev2-keyring-partner
peer partner
address 88.XXX.XXX.106
pre-shared-key *********************
!
crypto ikev2 profile ikev2-prof-partner
match identity remote address 88.XXX.XXX.106 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local ikev2-keyring-partner
crypto ipsec transform-set ipsec-prop-partner esp-gcm 256
mode tunnel
set transform-set ipsec-prop-partner
set ikev2-profile ikev2-prof-partner
match address crypto-acl-partner
ip access-list extended crypto-acl-partner
permit ip 10.101.0.0 0.0.255.255 192.168.2.0 0.0.0.255
I am stuck, and don’t know what else I could try. I have successfully setup several VPN tunnels to various entities, including IKEv2 to a Cisco-router, but I have no idea why this one does not work. I am only in email contact with the team on the Cisco side.
It shows packets of roughly 40-70 bytes trickling in. Which is puzzling, since the ipsec log indeed shows no sign of incoming traffic…
I must be missing something…
Post the anonymized export of the Mikrotik configuration - as the packets from the Cisco arrive but don’t make it to the IPsec stack, it must be something else (not IPsec related) in the configuration.
I’m not good at reading Cisco configs, could you clarify what party you expect to send initial contact? From the Mikrotik logs (“ike2 starting for” and config (no “passive=yes” on /ipsec peer) I gather you expect a Mikrotik to make initial contact. However, you also have “send-initial-contact=no” and mode-config is in responder mode.
To get a grasp of the situation best would be to sniff IPsec-related traffic on WAN (ports 500,4500, protocol UDP). First few packets related to Phase 1 are unencrypted.
I cannot see anything wrong in your configuration (I mean, the firewall rules could me a little bit more efficient but that’s a minor thing). Can you add log=yes to the action=accept chain=input in-interface=ether1-WAN src-address=34.XXX.XXX.251 rule and see in the log to what port the packets from 34.xxx.xxx.251 arrive?
It’s actually a misconception I’ve suffered from myself for years. The send-initial-contact parameter has nothing to do with controlling whether the peer will initiate connections or not - this is what the passive parameter controls. INITIAL_CONTACT is an optional notification, asking the peer receiving it to drop any existing IKE connections from the same source IP address and continue only with the one within which this INITIAL_CONTACT has arrived. EDIT: the above is not precise, see clarification here.
That doesn’t matter since the /ip ipsec identity row we’re dealing with here doesn’t refer to any mode-config at all.
34.XXX.XXX.251 is of course part of the VPN address-list.
Interestingly, this is something that puzzled me in the past, when successfully setting up other IPSec VPN’s - this rule did not show any traffic either.
The purpose of this rule of course is to only accept IPsec traffic from specific IP’s.
It is helpful in terms that we now know that they are not “ICMP destination unreachable” responses to the packets from your Mikrotik, but it doesn’t explain why the Mikrotik IPsec stack ignores them.
To see the contents, you have to sniff into a file and open the file using Wireshark.
/tool sniffer set file-name=ipsec.pcap
/tool sniffer quick ip-address=34.XXX.XXX.251
Let it run for a minute, then stop it, download the file an open it using Wireshark.
In your current case, the packets from 34.XXX.XXX.251 are accepted already by the rule accepting anything from that address, so they never reach this rule matching on src-address-list=VPN; in other cases, if your router sends a packet first, the response is accepted by the action=accept connection-state=established rule, so they also do not reach that rule matching on src-address-list=VPN.
Let’s hope I have done that right…
I guess we can see her both incoming and outgoing traffic?
The Cisco seems to send NAT-keepalive and ESP (SPI=xxxxxxxxxxxx) packets.
Where else the Mikrotik sends IKE_SA_INIT packets.
in other cases, if your router sends a packet first, the response is accepted by the action=accept connection-state=established rule, so they also do not reach that rule matching on src-address-list=VPN.
Ah I see, so the “VPN IPsec filter rule for UDP 500,4500” only ever hits if the other side initiates the VPN negotiation? That makes sense… So I guess I can leave it as it is?
The sniff shows that you’ve got another peer of 34.XXX.XXX.251 somewhere in the LAN of the RB750, which may explain why the Cisco ignores the IKE_SA_INIT packets sent by the RB750 itself.
/ip firewall connection print detail where src-address~“34.XXX.XXX.251” or dst-address~“34.XXX.XXX.251” should show you the IP address of that peer.
Hm. So there WAS a peer in the past, but it is not active at the moment, and the Cisco hasn’t found out yet - the connection shown is the one of the RB750 itself.
I’d say disable the peer on the RB750, give it an hour, and see whether the Cisco finds out that the connection went down. But it is strange, do you have any idea how that could have happened?
Well, we did experiment with this partner over the last couple of days with various VPN configurations. One of them was a IKEv1 config that actually did manage to establish a connection, but dropped the SA-keys immediately after establishing it.
So you want me to disable the entire VPN config (peer, policy, proposal etc) for an hour, and see if that connection went down - then try again? Can do that…
