Community discussions

MikroTik App
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 1:47 pm

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
Here's how I set up the Mikrotik VPN:
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha512 lifetime=1h name=NDA-DG

/ip ipsec peer
add address=34.XXX.XXX.251/32 comment="VPN NDA-DG" exchange-mode=ike2 name=NDA-DG profile=NDA-DG send-initial-contact=no

/ip ipsec proposal
add auth-algorithms=sha512 enc-algorithms=aes-256-gcm lifetime=8h name=NDA-DG pfs-group=modp2048

/ip ipsec identity
add comment="VPN NDA-DG" peer=NDA-DG secret=***********************************

/ip ipsec policy
add comment="VPN NDA-DG" dst-address=10.101.0.0/16 peer=NDA-DG proposal=NDA-DG sa-dst-address=34.XXX.XXX.251 sa-src-address=0.0.0.0 src-address=192.168.2.0/24 tunnel=yes
Here's what the Mikrotik log says:
12:39:54 ipsec ike2 starting for: 34.XXX.XXX.251 
12:39:55 ipsec adding notify: NAT_DETECTION_DESTINATION_IP 
12:39:55 ipsec adding notify: NAT_DETECTION_SOURCE_IP 
12:39:55 ipsec adding payload: NONCE 
12:39:55 ipsec adding payload: KE 
12:39:55 ipsec adding payload: SA 
12:39:55 ipsec <- ike2 request, exchange: SA_INIT:0 34.XXX.XXX.251[4500] 1c006823eafc81cb:0000000000000000 
12:39:55 ipsec,debug ===== sending 424 bytes from 88.XXX.XXX.106[4500] to 34.XXX.XXX.251[4500] 
12:40:00 ipsec ike2 init retransmit 
12:40:00 ipsec,debug ===== sending 424 bytes from 88.XXX.XXX.106[4500] to 34.XXX.XXX.251[4500] 
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.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 3:45 pm

The log shows that the Cisco peer neither responds your initial IKEv2 packets nor attempts to initiate the IKEv2 connection from its own side.

What does /tool traceroute 34.XXX.XXX.251 show?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 4:54 pm

Thank you for your response!
Traceroute shows this, however, I know the other side wont respond to ping. I know it's there though.
 1 88.XXX.XXX.105                     0%   10   0.7ms     0.6     0.5     0.7     0.1                                                                                
 2                                  100%   10 timeout                                                                                                                
 3 195.3.65.5                        30%   10     5ms     5.2       5     5.6     0.2                                                                                
 4 195.3.68.62                       90%   10 timeout     5.3     5.3     5.3       0                                                                                
 5 99.82.177.116                      0%   10   9.7ms     6.5     5.2     9.9     1.7                                                                                
 6 52.93.38.229                       0%   10   5.6ms     5.5     5.1     5.9     0.3 <MPLS:L=8584,E=0>                                                              
 7 52.93.38.131                       0%   10   5.4ms     9.5     5.1    31.2     7.9                                                                                
 8                                  100%   10 timeout                                                                                                                
 9                                  100%   10 timeout                                                                                                                
10                                  100%    9 timeout                                                                                                                
11                                  100%    9 timeout                                                                                                                
12                                  100%    9 timeout                                                                                                                                 
Also I added a firewall rule just to see if any traffic is coming in, and in fact there is!
/ip firewall filter
add action=accept chain=input comment="default configuration" in-interface=ether1-WAN src-address=34.XXX.XXX.251
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...
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 5:05 pm

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.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 8:06 pm

Please see attached config file. Thanks for your help!!
You do not have the required permissions to view the files attached to this post.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 8:32 pm

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.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 8:48 pm

Please see attached config file.
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?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 8:56 pm

From the Mikrotik ... 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"
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.

mode-config is in responder mode.
That doesn't matter since the /ip ipsec identity row we're dealing with here doesn't refer to any mode-config at all.
Last edited by sindy on Sun Sep 15, 2024 5:52 pm, edited 1 time in total.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 9:25 pm

Not sure if this is helpful:
20:20:36 firewall,info CISCO input: in:ether1-WAN out:(unknown 0), src-mac 20:83:f8:57:c4:98, proto UDP, 34.XXX.XXX.251:4500->88.XXX.XXX.106:4500, len 64 
20:20:38 firewall,info CISCO input: in:ether1-WAN out:(unknown 0), src-mac 20:83:f8:57:c4:98, proto UDP, 34.XXX.XXX.251:4500->88.XXX.XXX.106:4500, len 29 
20:20:41 firewall,info CISCO input: in:ether1-WAN out:(unknown 0), src-mac 20:83:f8:57:c4:98, proto UDP, 34.XXX.XXX.251:4500->88.XXX.XXX.106:4500, len 64 
20:20:46 firewall,info CISCO input: in:ether1-WAN out:(unknown 0), src-mac 20:83:f8:57:c4:98, proto UDP, 34.XXX.XXX.251:4500->88.XXX.XXX.106:4500, len 64 
20:20:48 firewall,info CISCO input: in:ether1-WAN out:(unknown 0), src-mac 20:83:f8:57:c4:98, proto UDP, 34.XXX.XXX.251:4500->88.XXX.XXX.106:4500, len 29 
How could I see the actual contents of the packets?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 9:35 pm

What's interesting is that this rule does not show any traffic:
/ip firewall filter
add action=accept chain=input comment=VPN protocol=udp src-address-list=VPN src-port=500,4500
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.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 9:37 pm

Not sure if this is helpful:
...
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.

How could I see the actual contents of the packets?
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.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 9:45 pm

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.
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.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 9:59 pm

Let's hope I have done that right...
wireshark.png
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.
You do not have the required permissions to view the files attached to this post.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:07 pm

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?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:12 pm

The Cisco seems to send NAT-keepalive and ESP (SPI=xxxxxxxxxxxx) packets.
Where else the Mikrotik sends IKE_SA_INIT packets.
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.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:14 pm

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?
Correct. You can even remove the rule accepting anything from 34.XXX.XXX.251.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:19 pm

Got the following response:
[admin@MikroTik Main-Router] > /ip firewall connection print detail where src-address~"34.XXX.XXX.251" or dst-address~"34.XXX.XXX.251"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat 
 0  SAC     protocol=udp src-address=88.XXX.XXX.106:4500 dst-address=34.XXX.XXX.251:4500 reply-src-address=34.XXX.XXX.251:4500 reply-dst-address=88.XXX.XXX.106:4500 timeout=2m59s 
            orig-packets=94 901 orig-bytes=30 195 575 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=175 599 repl-bytes=16 978 279 repl-fasttrack-packets=0 
            repl-fasttrack-bytes=0 orig-rate=3.6kbps repl-rate=232bps 
            
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:22 pm

Correct. You can even remove the rule accepting anything from 34.XXX.XXX.251.
Sure, it's only an easy way (for me) to see if there is even any traffic coming from that address. Will remove after the VPN actually works :-)
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:27 pm

Got the following response:
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?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:31 pm

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...
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:36 pm

It is enough to disable that particular peer, you may keep the rest enabled.

And from the ESP and UDP keepalives it is impossible to find out whether the connection has been established using IKE (v1) or IKEv2. What is clear is that it was NATed because otherwise the keepalives would not be there; double-check that by clicking at one of the ESP packets in the topmost pane (packet list) and see in the middle pane (dissection of individual packet) whether there is a UDP layer between the IP one and the ESP one. In the packet list, only the innermost protocol is usually shown.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:47 pm

Please forgive me Sir, I only understand 50% of what you are saying ;-)
I hope this screenshot reveals the information you wanted me to check?
wireshark2.png
You do not have the required permissions to view the files attached to this post.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:52 pm

I hope this screenshot reveals the information you wanted me to check?
Yes, it confirms that the ESP layer is encapsulated into UDP, which IPsec does if there is NAT somewhere between the peers. But it doesn't matter at which end, so it is also possible that 34.XXX.XXX.251 is not the actual address of the remote Cisco.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 11, 2022 10:56 pm

Thank you! Well I will leave the IPsec peer disabled over night, and see what happens tomorrow.
Thank you so much Sir for your help!! You did help me a great deal already :-)
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 12, 2022 2:08 am

@OriiOn it is possible to anonymize the captured packets: File -> Export Packet Dissections -> As Plain Text. Make sure to select "All expanded". After export, open the file in any text editor and replace IPs and MACs. With that you should be safe uploading it here.

If you have access to the Cisco router, you can use its SA database (SADB). There you can extract the keys that can be used to decrypt ESP packets.

Also consider setting Dead Peer Detection (DPD) interval on both Cisco and Mikrotik to some small intervals while you're testing.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 12, 2022 10:15 am

Before re-enabling the peer, sniff again - as you've mentioned previous attempts with IKE (v1), maybe the Cisco admin didn't change it back? The sniff should show you that, the initial packets differ between IKE (v1) and IKEv2.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 12, 2022 11:52 am

I followed @Kentzo's advice and exported the Wireshark sniff result as a text file. Please see attached file.
I am still receiving NAT-keepalive packets from the Cisco... How to interpret that?
Also, oddly, it seems the Mikrotik sends out ICMP packets to the Cisco, of which I am not aware of that I am doing this? I performed the traceroute (as you asked me to), which should have stopped when I closed the terminal? Other than that I can't think of any reason...

I did not re-activate the IPsec peer config yet.
You do not have the required permissions to view the files attached to this post.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 12, 2022 2:04 pm

The ICMP packets are sent by the IP stack of RouterOS as there is neither a tracked connection for the incoming UDP packets from 34.XXX.XXX.251 from UDP port 4500 to UDP port 4500 at 88.XXX.XXX.106, nor does any RouterOS process listen at that port, as you have probably disabled all peers, or at least all those using IKEv2. The ICMP packets say "destination unreachable, more precisely, port unreachable" as you can see not only in the dissection but also in the Info column of the packet list:
...
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
...
The fact that you keep getting NAT_keepalive packet most likely indicates that the Cisco still deems the IPsec session alive (unless the process sending them runs even after the SAs lifetimes have expired). The ESP packets are only sent if there is a need for them, i.e. when some payload packet matches the traffic selector and is getting encrypted and sent via IPsec.

What I was expecting to see, given the lifetimes of 1 h and 8 h for profile and proposal, respectively, was that the Cisco would be sending just SA_INIT by now. I can see no lifetime settings at the Cisco and I am not familiar with the defaults used by Cisco. Also the DPD (Dead Peer Detection) is probably not set at the Cisco end - @Kentzo's recommendation to activate it is a valid one.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 12, 2022 2:36 pm

Thank you again for all your explanations!
With that information I will approach the Cisco team.
Point is, the Cisco should have stopped sending anything by now. If anything it should send SA_INIT packets by now. Either they manually deactivate all IPsec related settings (as I did on my side) and/or they activate DPD with short lifespans, so that the connection is taken down through that mechanism.
Will get back again, as soon as I know more. Thanks again so much!
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 10:51 am

Is this Cisco config using crypto map or tunnel interphase for phase 1? I am wondering since it has the setting "mode tunnel" in it...
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 assuming that my Mikrotik configuration is the equivalent to what Cisco calls "crypto map", is this correct?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 11:14 am

I am wondering since it has the setting "mode tunnel" in it...
...
I am assuming that my Mikrotik configuration is the equivalent to what Cisco calls "crypto map", is this correct?
It's a vernacular issue. IPsec distinguishes between "transport mode" and "tunnel mode":
  • transport mode is intended for encryption of nothing but the own traffic between the peers, so the IP headers of the payload packets are not transported as the addresses of the transport packet are the same ones as those of the payload packet. So there is no point in wasting 20 bytes of packet space for just a copy of that information.
  • tunnel mode is intended to deliver any traffic (matching to the traffic selector, which has no special name in RouterOS and has been renamed to crypto map in IOS), so the IP header of the payload packet must be delivered too.
So yes, the Cisco settings do use a crypto map ACL to choose the traffic to be diverted to the IPsec SA in tunnel mode, not a VTI (Virtual Tunnel Interface). A VTI is breaking some of the security principles of IPsec, which may be the reason why Mikrotik hasn't implemented it.

Even if there was a mismatch in these settings (there isn't), you would see Phase 1 to succeed and Phase 2 to fail, which is not your case currently.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 12:26 pm

Thanks again for your reply! I am learning a lot......
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 5:19 pm

A VTI is breaking some of the security principles of IPsec, ...
Do you have few more words or some suggested reading about that?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 5:36 pm

Whatever reverse-matches a traffic selector of an existing IPsec policy, even of an inactive one, but did not arrive via the security association linked to that policy, must be dropped. Use of VTI breaks this principle. I know, I know, so does you-name-it over IPsec.

But it may be a bit complex to implement - the traffic selectors are negotiated between the peers, and for a security association used to transport traffic between two VTIs, the traffic selector must be 0.0.0.0/0<->0.0.0.0/0 (because you never know what will be routed via the tunnel). So to implement a VTI, you'd likely have to modify the IPsec code quite a lot so that these selectors were negotiated with the peer but not used locally to redirect/drop traffic, whilst the encapsulation and decapsulation would have to remain the same.
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 6:26 pm

Don't get me wrong, I was just wondering what I missed. And you're right. I'm not the biggest fan of IPSec myself, the thing is a bit weird, how it stands aside from other things and how it interacts with them (e.g. when it needs existing route to destination, but doesn't really use it). And interfaces are nice to have. :)
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 7:56 pm

Whatever reverse-matches a traffic selector of an existing IPsec policy, even of an inactive one, but did not arrive via the security association linked to that policy, must be dropped. Use of VTI breaks this principle. I know, I know, so does you-name-it over IPsec.

But it may be a bit complex to implement - the traffic selectors are negotiated between the peers, and for a security association used to transport traffic between two VTIs, the traffic selector must be 0.0.0.0/0<->0.0.0.0/0 (because you never know what will be routed via the tunnel). So to implement a VTI, you'd likely have to modify the IPsec code quite a lot so that these selectors were negotiated with the peer but not used locally to redirect/drop traffic, whilst the encapsulation and decapsulation would have to remain the same.
Why do you say two VTIs?

Couldn’t one still have an interface with the following flow:

- Do not let anything that does not meet current policies into the interface (preflight check)
- Ditto after regular RouterOS processing (postflight check).

Policy rules are quite simple and this double-check should not introduce a noticeable delay.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 8:09 pm

Why do you say two VTIs?
Simply because VTI is a Virtual Tunnel Interface, so the packets are sent into the tunnel through one VTI at one router and emerge from the tunnel via the other VTI on the other router. Hence "traffic between two VTIs".

Couldn’t one still have an interface with the following flow:
...
Policy rules are quite simple and this double-check should not introduce a noticeable delay.
I'm not sure what you have in mind - that the traffic selector for an SA carrying the tunnel between the VTIs could be different than 0.0.0.0/0<->0.0.0.0/0 or that the modification of the current flow, where all incoming traffic is always matched against all the existing IPsec traffic selectors to check that it has arrived the proper way, should not be too complicated?
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 13, 2022 10:49 pm

Oh I’m just trying to match my understanding of IPsec and its requirements that makes supporting VTIs no trivial.

Why should the OS care whether the opposite side has a VTI? Shouldn’t VTI on one side work just as well with VTI-less client/responder?

When you speak about VTIs do you mean a VTI per IPsec group of peers & policies? If so, cannot you just drop all the “unexpected” traffic before it “hits” the VTI, why this dance with 0.0.0.0 <-> 0.0.0.0?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Feb 14, 2022 11:25 am

From the end - from the usage point of view, what is called "VTI" in the IPsec context is equivalent to any plain point-to-point tunnel like all the flavors of PPP, GRE in L3 mode, or IPIP (IPencap) - what you throw in at one end will fall out at the other end. So no way to link a group of peers and/or policies to a single Virtual Tunnel Interface (similar to the "router inside a router" arrangement the Wireguard implementation on Mikrotik provides, with multiple peers linked to the same Wireguard interface, and allowed-address rows specifying which traffic will go to/will be accepted from which of the peers). A given VTI must always be linked to a single peer. Just not to be misunderstood - I'm not saying this would not be technically possible, I'm just saying it would differ from the common understanding of what VTI means in the IPsec context.

Now your thinking is correct that a peer with VTI implemented may establish an SA with a peer with no knowledge of VTI - there is no standard specifying any distinctive header fields in the ESP packets indicating that what they carry is a VTI traffic, or any indication during the SA negotiation that the traffic will not be chosen using the traffic selector.

It even works this way but the use cases are very limited. The thing is that the negotiation of traffic selectors is a mandatory step of the SA establishment. So to accept a 0.0.0.0/0<->0.0.0.0/0 from the remote peer supporting the VTI, the local peer not supporting it must also use 0.0.0.0/0<->0.0.0.0/0. But since the local peer doesn't support VTI, this 0.0.0.0/0<->0.0.0.0/0 becomes the actual traffic selector. So it handles all the local traffic the IPsec way. The only way to exempt traffic from hitting this traffic selector is to provide another traffic selector before this one. And it takes just 31 additional traffic selectors to exempt traffic towards any destination except a single IP address from getting caught by the 0.0.0.0/0<->0.0.0.0/0 one. Plus you can do this only once, because the first 0.0.0.0/0<->0.0.0.0/0 selector will shadow all the subsequent ones. So not more than a single "non-VTI VTI" per device.

So to make use of the flexibility of the VTI (which is in fact functionally equivalent to an IPsec-encrypted IPIP tunnel but not interoperable with it due to the traffic selector negotiation), both peers must support it.

And the implementation complication I can see is that it requires to add conditional branchings here and there into the existing IPsec stack, which always imposes a risk of breaking something somewhere without noticing that immediately, and that's what you want least with a security solution.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Feb 14, 2022 11:10 pm

So to accept a 0.0.0.0/0<->0.0.0.0/0 from the remote peer supporting the VTI, the local peer not supporting it must also use 0.0.0.0/0<->0.0.0.0/0.

I'm likely missing something obvious about VTIs, IPsec or some specific use-case.

I still don't understand why a VTI requires negotiation of 0.0.0.0/0<->0.0.0.0/0 before other policies can be applied. Since VTI represents a connection (persistent or dynamic?) to a specific peer with specific policies, why cannot it simply drop the traffic that does not match any of the negotiated selectors. If user tries to route traffic that does not match any selectors then drop it or issue an appropriate ICMP. Same for traffic from the IPsec connection counterpart.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Feb 14, 2022 11:37 pm

I still don't understand why a VTI requires negotiation of 0.0.0.0/0<->0.0.0.0/0 before other policies can be applied.
Because the IPsec RFC requires that the traffic selector was negotiated as part of the process of establishing the pair of security associations for transport of encrypted payload data, and because it also requires that the recipient dropped any payload packet received via the security association if it does not match the negotiated traffic selector.

It's not "before other policies can be applied" - the 0.0.0.0/0<->0.0.0.0/0 is the only selector to be used along with the VTI.

Since VTI represents a connection (persistent or dynamic?) to a specific peer with specific policies, why cannot it simply drop the traffic that does not match any of the negotiated selectors. If user tries to route traffic that does not match any selectors then drop it or issue an appropriate ICMP. Same for traffic from the IPsec connection counterpart.
Because that would deny the very purpose of IPsec VTI, which is that you can use it the same way like any other tunnel interface, i.e. send any traffic through it. And the only selector to match "any traffic" is 0.0.0.0/0<->0.0.0.0/0.

It seems to me that you keep following the mental model where the VTI represents a single point of entry to a trunk of multiple policies (i.e. traffic selector to security association mappings), but none of the vendors that support VTI uses this approach. In the IPsec context, the very idea of VTI is to avoid the IPsec traffic selection approach completely, as it is so much different from the "normal routing" (and so limiting when it comes to redundancy - no alternative paths so no dynamic routing).
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 15, 2022 12:08 am

It seems to me that you keep following the mental model where the VTI represents a single point of entry to a trunk of multiple policies (i.e. traffic selector to security association mappings), but none of the vendors that support VTI uses this approach. In the IPsec context, the very idea of VTI is to avoid the IPsec traffic selection approach completely, as it is so much different from the "normal routing" (and so limiting when it comes to redundancy - no alternative paths so no dynamic routing).
Yeah, that seems to be my train of though: a VTI as dynamically created entry by the existing IPsec stack in addition to everything else. Akin to an active peer.

Having VTI to replace conventional (RFC required?) IPsec data structures did not occur to me. So the idea is to have this VTI to implicitly manipulate IPsec connection as needed to accommodate current routing table. But is this possible in a general case? The way I read RFC 7296, 2.9 (2.9.2 specifically) it cannot be done. Is this the reason for 0.0.0.0/0<->0.0.0.0/0? But then you kind of throw away much of the protocol and render many aspects of IKEv2 redundant. Don't you end up with a completely different beast in that case that's only somewhat based on IPsec's IKEv2?

Could you point me to a vendor that has a state-of-the-art IPsec VTI?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 15, 2022 12:17 am

Cisco, Fortinet, ...

2.9.2 is not actually relevant, it basically just says "don't screw an already negotiated TS during rekeying".
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 15, 2022 12:28 am

But then you kind of throw away much of the protocol and render many aspects of IKEv2 redundant. Don't you end up with a completely different beast in that case that's only somewhat based on IPsec's IKEv2?
If you understand "protocol" in the wider sense, i.e. including the required handling inside the router, then it's exactly what VTI does - bypasses most of this handling required by RFC 7296 and RFC 4301, i.e. it indeed throws away most of the security model of IPsec. But to keep it compatible on the wire (i.e. in the narrower sense of the "protocol" meaning), it has to keep the traffic selector negotiation.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 15, 2022 12:47 am

Cisco's IPsec DVTI does not seem to require any <-> any policy as it expects a set of specific policies. Thus it can negotiate a very specific set of selectors, no need to "lie" and maintain a proprietary behavior where any <-> any is actually negotiated on the wire.

So again, not sure why 0.0.0.0/0<->0.0.0.0/0 is required.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 15, 2022 9:20 am

Cisco's IPsec DVTI does not seem to require any <-> any policy as it expects a set of specific policies.
...
In that case, I didn't dig deep enough into Cisco's settings. I've only seen an any<->any offer.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 2:44 pm

Not sure if I should start this in a new thread? @Admins: feel free to split this.

Okay, IPsec basics: I am not a 100% certain, but so far I was under the assumption that RouterOS's "Proposal" settings == Phase1 and "Profile" settings == Phase 2? I think I might be wrong on this assumption?

"Policy" is linked with "Proposal", right?
"Peer" is linked with "Profile", correct?
So, if I disable "Policy", and enabled "Peer" I see IPsec traffic in the logs already... to me that indicates that Peer/Profile == Phase 1 !? So the opposite of what I believe(d) until now...

So far I did not really notice the difference, because I tend to use the same settings (Auth Algo/Hash, Encryption and DH Group) for phase 1 and phase 2.
Also I am under the assumption Phase 1 is the one with longer lifetime (eg 8h), and phase 2 is the one with the shorter lifetime (eg 1h).

So which settings is phase 1 and phase 2? And which phase is the one with the "longer lifetime"?

Thanks for answering these really basic questions...
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 3:25 pm

"Policy" is linked with "Proposal", right?
A policy is what links a traffic selector (which does not exist as a separate configuration item, its components are parameters on the policy row), proposal, and peer together. And it is related to establishing a security association for transportation of payload, so Phase 2.
"Peer" is linked with "Profile", correct?
Some parameters of a peer (like the encryption&authentication proposal) are aggregated into a profile. The parameters of the peer and profile are related to establishing a security association for negatiation of the whole "IPsec session" between the peers, i.e. Phase 1.

Those default lifetimes are mostly related to the expected amount of traffic being transported and the fact that the more data you've got, the easier it is to break a cipher. So Phase 2 SAs are rekeyed more frequently as they are suspected to transport much more data per unit of time than the Phase 1 SA.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 5:46 pm

Thank you again for your sophisticated and detailed answer!
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 6:45 pm

So Phase 2 SAs are rekeyed more frequently as they are suspected to transport much more data per unit of time than the Phase 1 SA.
What is interesting is that RouterOS generates a default Proposal (phase 2) with a lifetime of 1d, and a default Profile (phase 1) with a lifetime of 1h.
Shouldn't the longer lifetime be assigned to phase 1?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 6:59 pm

RouterOS generates a default Proposal (phase 2) with a lifetime of 1d, and a default Profile (phase 1) with a lifetime of 1h.
Shouldn't the longer lifetime be assigned to phase 1?
On which RouterOS version this happens, and how exactly do you create the profile and proposal?

When I add a new profile and a new proposal using command line on my favourite 6.47.10, specifying nothing but the name, the lifetime is set to 1d for a profile and to 30m for a proposal.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Feb 22, 2022 11:11 pm

When I add a new profile and a new proposal using command line on my favourite 6.47.10, specifying nothing but the name, the lifetime is set to 1d for a profile and to 30m for a proposal.
I can actually confirm that for 6.47.1

I mean the default profile and proposal
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=1h
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1d pfs-group=modp2048
However, they may well be remnants of previous older versions of RouterOS. I did not add them, these profiles were already there as part of the default configuration. I would have to reset the configuration to see the behavior of the current OS.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 2:26 pm

We're still trying to get the VPN to work... this time trying IKE v1 (main).
Phase 1 establishes, but phase 2 seems to fail:
12:38:13 ipsec,debug proposal #1: 1 transform 
12:38:13 ipsec,debug got the local address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255 
12:38:13 ipsec,debug got the peer address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255 
12:38:13 ipsec searching for policy for selector: 0.0.0.0/0 <=> 0.0.0.0/0 
12:38:13 ipsec policy not found 
12:38:13 ipsec failed to get proposal for responder. 
12:38:13 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet. 
12:38:13 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet.
I believe the settings responsible for the IP's to show as 0.0.0.0/0 are in Identity?
My ID Type is set to auto.
Remote ID Type is set to auto.
Match By is set to remote id

I am using these settings for various tunnels, and it has always worked.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 2:29 pm

As they ask for a 0.0.0.0/0<=>0.0.0.0/0 traffic selector, this looks to me as if they now had a VID at Cisco side.

Something is telling me that with IKE (v1), traffic selectors cannot be negotiated, just accepted or rejected. But I can't give you a reference to a particular RFC.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 8:08 pm

It doesn’t, but it can be tolerated as traffic selector is not a route selector. I.e. the router shouldn’t start routing all traffic through IPsec, merely use the same SA for all its traffic.

Have you tried adding this specific, non-template, policy?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 8:17 pm

It doesn’t, but it can be tolerated as traffic selector is not a route selector. I.e. the router shouldn’t start routing all traffic through IPsec, merely use the same SA for all its traffic.
On Mikrotik (and in vanilla IPsec in general) it's different - traffic selector of an enabled policy overrides any result of routing. So you can add a policy with a 0.0.0.0/0 <=> 0.0.0.0/0 selector, but to prevent all traffic from being redirected to its linked SA, you have to put some other policies before it to prevent their corresponding traffic from reaching that one. Either with action=none to keep the result of regular routing, or with action=encrypt and another SA or even peer.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 8:30 pm

Hmm, isn’t routing controlled with split-include?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 8:35 pm

Have you tried adding this specific, non-template, policy?
I haven't. However, to me this seems an odd work around to fix some other underlying issue.

Unfortunately I am not a router or VPN expert, and only understand the basics. Neither seems to be the team on the other side, that is supposed to configure their Cisco, because it's taking weeks to setup a simple VPN.... IKEv2 doesn't work because the Cisco does not even respond to "my" SA_INIT packets. IKEv1 does not work, because of this issue...

I'd rather understand where this "0.0.0.0/0 <=> 0.0.0.0/0 selector" issue is stemming from? Is this something I misconfigured on the RouterOS side? What exactly causes this on the Cisco side?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 8:57 pm

I'd rather understand where this "0.0.0.0/0 <=> 0.0.0.0/0 selector" issue is stemming from? Is this something I misconfigured on the RouterOS side? What exactly causes this on the Cisco side?
You've provided just a short excerpt from the log, but from there it seems to me that the offer for such a selector comes from Cisco side.

If the eest of the setup of your router is simple enough, you can follow @Kentzo's advice after first configuring enough action=none policies preventing any traffic but the required one from reaching the 0.0.0.0/0 <=> 0.0.0.0/0 policy.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Fri Feb 25, 2022 10:54 pm

I find it hard to believe that IKEv2 cannot be made to work between Cisco and RouterOS. There are proprietary extensions, but not to the point of leaving IPsec totally broken.

What was the last issue with it?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 26, 2022 12:55 am

I can get the VPN to establish successfully, by adding a 0.0.0.0/0 <=> 0.0.0.0/0 policy.
However, I don't know exactly how I have to setup the "action=none" policies, to avoid ordinary traffic ending up in the tunnel.
While the config on this test-router I am using here is quite simple, the config on the actual production router is a lot more complicated - so I don't think this is a viable solution.

You've provided just a short excerpt from the log, but from there it seems to me that the offer for such a selector comes from Cisco side.
Would it help if I provided the full log?
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 26, 2022 1:50 am

It wouldn't harm :)

But I find wireshark captures helpful to debugging some fundamental protocol misunderstanding (it's also very educational), since they can be straightforwardly mapped into actual RFCs. Logs are, after all, results of Mikrotik's processing and may hide the issue.

However, I don't know exactly how I have to setup the "action=none" policies, to avoid ordinary traffic ending up in the tunnel.

If I understand @sindy correctly, just add more specific policies (i.e. specific source addr. and/or destination addr. and/or protocols) and the same group and proposal, but set the action to none (perhaps you also need to set level to "use"?). Note that the list of policies is an an ordered one, so put them before "0.0.0.0/0 <=> 0.0.0.0/0". The net result should be:

1. During the negotiation "0.0.0.0/0 <=> 0.0.0.0/0" will be found which will let phase 2 to complete and establish communication SAs
2. The none policies will, hopefully, prevent RouterOS from routing through IPsec

Note that on RouterOS you can control even further what can go through IPsec via ipsec-policy parameter of a filter rule. I have not tried it, but looks like it allows to describe very complex setups by the means of marks.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sat Feb 26, 2022 11:21 am

I find wireshark captures helpful to debugging some fundamental protocol misunderstanding (it's also very educational), since they can be straightforwardly mapped into actual RFCs. Logs are, after all, results of Mikrotik's processing and may hide the issue.
Wireshark is perfect to tell you what has happened, provided that you are able to decrypt the protocol messages. Phase 1 becomes encrypted quite soon. So to see the actual contents of these packets in plaintext, you may still need the log which dumps the Phase 1 packet contents in decrypted form. There is a topic here on the forum on how to read these using Wireshark. Not sure it works for both directions of Phase 1, though.

Log is the best source to learn why something happened, i.e. why the side generating the log has taken a particular decision.

However, I don't know exactly how I have to setup the "action=none" policies, to avoid ordinary traffic ending up in the tunnel.
If I understand @sindy correctly, just add more specific policies (i.e. specific source addr. and/or destination addr. and/or protocols) and the same group and proposal, but set the action to none (perhaps you also need to set level to "use"?). Note that the list of policies is an an ordered one, so put them before "0.0.0.0/0 <=> 0.0.0.0/0". The net result should be:

1. During the negotiation "0.0.0.0/0 <=> 0.0.0.0/0" will be found which will let phase 2 to complete and establish communication SAs
2. The none policies will, hopefully, prevent RouterOS from routing through IPsec
Yes, that's the idea. There is no need for a proposal or a peer in action=none policies.

Example - you want that only packets from a local subnet 10.0.0.0/8 to a remote subnet 11.0.0.0/8 reach the 0.0.0.0/0 <=> 0.0.0.0/0 policy. This is intentionally simplified to keep the number of policies low for the purpose of the example.

So you have to use action=none policies with the following traffic selectors:
src-address=128.0.0.0/1 dst-address=0.0.0.0/0
src-address=64.0.0.0/2 dst-address=0.0.0.0/0
src-address=32.0.0.0/3 dst-address=0.0.0.0/0
src-address=16.0.0.0/4 dst-address=0.0.0.0/0
src-address=0.0.0.0/5 dst-address=0.0.0.0/0
src-address=12.0.0.0/6 dst-address=0.0.0.0/0
src-address=8.0.0.0/7 dst-address=0.0.0.0/0
src-address=11.0.0.0/8 dst-address=0.0.0.0/0

src-address=0.0.0.0/0 dst-address=128.0.0.0/1
src-address=0.0.0.0/0 dst-address=64.0.0.0/2
src-address=0.0.0.0/0 dst-address=32.0.0.0/3
src-address=0.0.0.0/0 dst-address=16.0.0.0/4
src-address=0.0.0.0/0 dst-address=0.0.0.0/5
src-address=0.0.0.0/0 dst-address=12.0.0.0/6
src-address=0.0.0.0/0 dst-address=8.0.0.0/7
src-address=0.0.0.0/0 dst-address=10.0.0.0/8


The blue ones catch packets from any source except 10.0.0.0/8 to any destination; the green ones catch packets to any destination except 11.0.0.0/8.

So for a /8 source or destination network, you need 8 policies; for a /24 one, you need 24 policies. And if there are more subnets to let pass, it becomes a nightmare that can only be generated using a script.

Worse than that, in some cases Mikrotik acting as a responder rejects 0.0.0.0/0 at destination side as a "safety measure". I'm not sure whether it is the case also for a statically configured policy or only for ones generated from a template.

Note that on RouterOS you can control even further what can go through IPsec via ipsec-policy parameter of a filter rule. I have not tried it, but looks like it allows to describe very complex setups by the means of marks.
Unfortunately, it's the other way round. The ipsec=in|out,ipsec|none match conditions only allow the firewall rules to treat received packets depending on whether they came in via an IPsec policy or not, and packets being sent or forwarded out depending on whether they will match a traffic selector of an IPsec policy if they ever reach it. So basically you can use in-interface-list=WAN ipsec-policy=in,ipsec to match only packets that came in IPsec-encrypted via WAN (e.g. to accept them for management access) or ipsec-policy=out,ipsec to match packets that will get encrypted, e.g. to exempt them from being src-nated (which would prevent them from matching the traffic selector and thus get encrypted).

In summary - in RouterOS there is no way to protect a packet on its way to be sent out from being diverted by a policy except two things - another policy or src-nat.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 12:17 am

Here's the full log
23:05:34 is when phase 1 is initiated
23:05:48 is when a suitable policy can't be found, and the SA's are purged
23:06:02 dont know what happens here
23:06:05 apparently receiving some more data from the cisco
You do not have the required permissions to view the files attached to this post.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 12:27 am

Not sure it works for both directions of Phase 1, though.

RouterOS logs keys for both directions and Wireshark also allows to set both of them.

Yes, that's the idea. There is no need for a proposal or a peer in action=none policies.

Do you know how policy's level fits into this configuration? Cannot quite grasp when I would want to touch it, but from the description it seems to be useful here.

Note that on RouterOS you can control even further what can go through IPsec via ipsec-policy parameter of a filter rule. I have not tried it, but looks like it allows to describe very complex setups by the means of marks.
Unfortunately, it's the other way round.

Hmm, cannot it be used to control what traffic originating from RouterOS-side of connection can reach IPsec, e.g. via a mangle rule. Is it too late for that?
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 6:52 am

Here's the full log

In the log I see this:

23:05:48 ipsec,debug proposal #1: 1 transform
23:05:48 ipsec,debug got the local address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255
23:05:48 ipsec,debug got the peer address from ID payload 0.0.0.0[0] prefixlen=0 ul_proto=255
23:05:48 ipsec searching for policy for selector: 0.0.0.0/0 <=> 0.0.0.0/0
23:05:48 ipsec policy not found
23:05:48 ipsec failed to get proposal for responder.
23:05:48 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet.
23:05:48 ipsec,error 34.XXX.XXX.251 failed to pre-process ph2 packet.

This seems the same as in your post #53. Are you sure peer's exchange mode was set to "IKEv2"? I count 6 back-n-forth message before a security association is established for the ISAKMP traffic (encryption for traffic that controls IPsec connection, which is separate from data encryption) which suggest peer's exchange mode "main".
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 10:36 am

Do you know how policy's level fits into this configuration? Cannot quite grasp when I would want to touch it, but from the description it seems to be useful here.
The description in the manual is not really clear, but level only controls the process of setting up SAs. So for action=none, it is irrelevant.
In general, unique means that a dedicated pair of SAs is created per each traffic selector (policy), and require means that all traffic selectors may (policies) use the same pair of SAs. I've never understood the purpose of use.

Unfortunately, it's the other way round.
Hmm, cannot it be used to control what traffic originating from RouterOS-side of connection can reach IPsec, e.g. via a mangle rule. Is it too late for that?
Traffic selector matching is the very last step of packet processing, just before actually sending the packet to the gateway chosen by routing, and it ignores any marks, it only checks addresses, protocols, and where applicable, ports. That's why so many people ask for VTI.

You can specify a connection-mark value in /ip ipsec mode-config, but that's used to create a src-nat rule matching on that connection-mark value on an initiator, to change the source address of traffic matching that connection-mark to the one assigned by the responder.

Are you sure peer's exchange mode was set to "IKEv2"?
I'm sure he's sure it was not:
We're still trying to get the VPN to work... this time trying IKE v1 (main).
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 12:32 pm

The log stems indeed from an IKE v1 (main) connection attempt.
So I figure the log does not reveal the cause for selector 0.0.0.0/0 <=> 0.0.0.0/0, neither does it reveal which side (RouterOS or Cisco) is causing this?
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 2:10 pm

So I figure the log does not reveal the cause for selector 0.0.0.0/0 <=> 0.0.0.0/0, neither does it reveal which side (RouterOS or Cisco) is causing this?
It does reveal that the requirement for selector 0.0.0.0/0 <=> 0.0.0.0/0 came from the Cisco side. Why Cisco requires it is a different story - I think this time they've set the VTI mode, but I'd have to see their config to confirm that.

As for the same router to be used for this Cisco and for other peers - if this Cisco should stay with 0.0.0.0/0 <=> 0.0.0.0/0, you'd have to use another router at your side to serve only this connection if you wanted to stay with bare IPsec (or get insane from the exceptional policies), but it seems way better to me to use IPIP over IPsec. If both peers have public addresses (well, to be precise - directly routable ones with no NAT in between them), IPIP over IPsec in transport mode has the same overhead like a VTI in tunnel mode. I run it against Cisco somewhere, but I admit I use IKEv2 there.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Feb 27, 2022 10:15 pm

The log stems indeed from an IKE v1 (main) connection attempt.
Ah, sorry. My offer of help was regarding IKEv2. I didn't bother to read IKEv1 RFCs, sorry.
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Feb 28, 2022 12:19 pm

I asked for their current full (IKE v1) config. This is what I got:
crypto keyring keyring-vpn-livesports  
  local-address GigabitEthernet1
  pre-shared-key address 88.XXX.XXX.106 key ***********************
crypto isakmp profile isakmp-vpn-livesports
   keyring keyring-vpn-livesports
   match identity address 88.XXX.XXX.106 255.255.255.255 
   local-address GigabitEthernet1
crypto ipsec transform-set ipsec-prop-vpn-livesports esp-aes 256 esp-sha256-hmac 
 mode tunnel
crypto ipsec profile ipsec-vpn-livesports
 set transform-set ipsec-prop-vpn-livesports 
 set pfs group5
 set transform-set ipsec-prop-vpn-livesports 
 set isakmp-profile isakmp-vpn-livesports
 match address crypto-acl-livesports2
ip access-list extended crypto-acl-livesports2
 permit ip 10.101.0.0 0.0.255.255 192.168.2.0 0.0.0.255
 permit ip 192.168.2.0 0.0.0.255 10.101.0.0 0.0.255.255
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Feb 28, 2022 11:16 pm

I do not see a static VTI. The access list for the profile is also quite specific. Not sure why Cisco actually sends 0.0.0.0
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Mar 01, 2022 1:11 pm

We finally got the VPN to work (IKEv1), by making sure the Cisco router only acts as responder (passive). That way we avoid the 0.0.0.0/0<=>0.0.0.0/0 selector issue.
Thanks again to everyone for the help and the insights, which certainly improved my general understanding of VPN's.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 617
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Tue Mar 01, 2022 9:10 pm

We finally got the VPN to work (IKEv1), by making sure the Cisco router only acts as responder (passive). That way we avoid the 0.0.0.0/0<=>0.0.0.0/0 selector issue.
Thanks again to everyone for the help and the insights, which certainly improved my general understanding of VPN's.
For further readers, could you share current Cisco and RouterOS configs that work?
 
OriiOn
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 89
Joined: Thu Feb 25, 2010 11:54 am

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Wed Mar 02, 2022 2:44 am

Well it's the configuration that I posted in this thread, for both RouterOS and Cisco. It's a very ordinary setup - one that I have used a dozen times (including to other Cisco routers without any issue what so ever).

Why in this case we ran into the 0.0.0.0/0<=>0.0.0.0/0 selector issue we still do not know.
Also we have no idea why the IKE v2 config did not work at all (no incoming traffic from the Cisco). I guess they have some sort of general issue with their Cisco setup, but we will never find out, because the team operating the Cisco router is not very communicative...

Thanks though for your help!
 
lfoerster
newbie
Posts: 37
Joined: Mon Mar 07, 2022 1:29 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Mon Mar 14, 2022 5:58 pm

Maybe this is helpful to solve the issue:
https://administrator.de/contentid/544054
This IKEv2 config is running fine without any issues.
 
User avatar
Damago1
just joined
Posts: 13
Joined: Wed Jan 10, 2024 9:25 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Sep 15, 2024 5:45 pm

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.
Man! Where can you find any documentation or book or presentation clarifying such things? I am struggling to understand how ipsec is actually handled by Mikrotik and every step there are suprises like this above with parameter not doing what it would be logical from the name and wiki.
 
User avatar
sindy
Forum Guru
Forum Guru
Posts: 11017
Joined: Mon Dec 04, 2017 9:19 pm

Re: Mikrotik <-> Cisco IPsec IKEv2 VPN

Sun Sep 15, 2024 5:50 pm

Reading RFCs is often helpful. Also, I would swear I have seen somewhere the INITIAL_CONTACT to cause connections from the same address to be dropped as written above, but today I could only find in both RFC 5996 and RFC 4306 that it is related to connections authenticated using the same credentials (which makes much more sense of course).

Who is online

Users browsing this forum: eworm, johnson73, rockyinc and 61 guests