IPSec tunnel to Cisco fails in phase 2

Hi, I’m trying to set up an IPSec tunnel between my Cisco IOS router and my RouterOS (RB750G).

Cisco:
Private net: 10.10.10.0/24
Public IP: 24.19.XX.XX

RouterOS:
Private net: 192.168.88.0/24
Public IP: 221.221.XX.XX

And the relevant configuration snippets:

crypto keyring keyring-qin 
  pre-shared-key address 221.221.XX.XX key *******

crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2  
 lifetime 28800

crypto isakmp profile isakmp-qin
   keyring keyring-qin
   match identity address 221.221.XX.XX 255.255.255.255 

crypto ipsec transform-set ipsec-prop-qin esp-aes esp-sha-hmac 

crypto ipsec profile ipsec-qin
 set transform-set ipsec-prop-qin 
 set pfs group2

interface Tunnel3
 no ip address
 ip virtual-reassembly
 ip tcp adjust-mss 1396
 tunnel source FastEthernet4
 tunnel destination 221.221.XX.XX
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile ipsec-qin



/ip ipsec peer
add address=24.19.XX.XX/32:500 auth-method=pre-shared-key comment="" \
    dh-group=modp1024 disabled=no dpd-interval=disable-dpd \
    dpd-maximum-failures=1 enc-algorithm=aes-128 exchange-mode=main \
    generate-policy=no hash-algorithm=sha1 lifebytes=0 lifetime=1d \
    nat-traversal=no proposal-check=obey secret=******* \
    send-initial-contact=no

/ip ipsec policy
add action=encrypt comment="" disabled=no dst-address=10.10.10.0/24:any \
    ipsec-protocols=esp level=require priority=0 proposal=default protocol=\
    all sa-dst-address=24.19.XX.XX sa-src-address=221.221.XX.XX src-address=\
    192.168.88.0/24:any tunnel=yes

/ip firewall nat
add action=accept chain=srcnat comment="" disabled=no dst-address=\
    10.10.0.0/16 src-address=192.168.88.0/24
add action=masquerade chain=srcnat comment="" disabled=no

The Cisco attempts to establish the tunnel to the RouterOS box, and I can see from the cisco debug output that phase 1 completes but it stalls on phase 2 (retransmits IKE until it gives up). I can see on the RouterOS side that is also see phase 1 completing but it’s rejecting phase 2, I guess because the policy doesn’t match:

echo: ipsec respond new phase 1 negotiation: 221.221.XX.XX[500]<=>24.19.XX.XX[500]
echo: ipsec begin Identity Protection mode.
echo: ipsec received Vendor ID: RFC 3947
echo: ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
echo: ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
echo: ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
echo: ipsec
echo: ipsec received Vendor ID: DPD
echo: ipsec received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
echo: ipsec ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
echo: ipsec ISAKMP-SA established 221.221.XX.XX[500]-24.19.XX.XX[500] spi:f18eed2437f97de4:0a3adb1ee5ce46f0
echo: ipsec respond new phase 2 negotiation: 221.221.XX.XX[500]<=>24.19.XX.XX[500]
echo: ipsec no policy found: 0.0.0.0/0[0] 0.0.0.0/0[0] proto=any dir=in
echo: ipsec failed to get proposal for responder.
echo: ipsec failed to pre-process packet.
echo: ipsec respond new phase 2 negotiation: 221.221.XX.XX[500]<=>24.19.XX.XX[500]
echo: ipsec no policy found: 0.0.0.0/0[0] 0.0.0.0/0[0] proto=any dir=in
echo: ipsec failed to get proposal for responder.
echo: ipsec failed to pre-process packet.

It looks like Cisco is proposing 0.0.0.0/0 and RouterOS is rejecting this because it expects 192.168.88.0/24 <==> 10.10.10.0/24.

I tried to apply a crypto map to my Cisco’s public interface with an appropriate ACL to match this, but there is already a crypto map on the interface for remote VPN users. So I added it to the existing map, but still no dice (same problem).

crypto map vpn_clientmap client authentication list vpn_userauthen
crypto map vpn_clientmap isakmp authorization list vpn_groupauthor
crypto map vpn_clientmap client configuration address respond
crypto map vpn_clientmap 10 ipsec-isakmp 
 set peer 221.221.XX.XX
 match address 150
crypto map vpn_clientmap 20 ipsec-isakmp dynamic vpn_dynmap 

access-list 150 permit ip 10.10.10.0 0.0.0.255 192.168.88.0 0.0.0.255

interface FastEthernet4
 crypto map vpn_clientmap

Can anyone suggest what I need to do to get these proposals to match up?

Thanks!

Well I opened a TAC request with Cisco, we’ll see what they say.

Maybe I’m missing something with ROS, but it seems like the way the /ip ipsec policy works is you have to know all the destination networks that you will be communicating with over IPSec at configuration time. Suppose, for example, I want to do a hub and spoke model, where I have a central office and a number of satellite offices, and I want the satellite offices to be able to communicate with each other via the central office. Each satellite office then needs to know the network addresses of the other satellite offices so that it can have a policy for it, right?

The way I’ve got the Cisco configured is I have a tunnel interface in ipsec tunnel mode to the other satellite offices (with src/dest traffic to encrypt = 0.0.0.0/0, so all traffic that goes over the tunnel is encrypted). Then the offices advertise their private network range over BGP via this tunnel. So the satellites know to route traffic to the central office and any connected satellite office over the ipsec tunnel they’ve got to the central office.

Is there any way to do such a configuration in ROS?

Well it seems the tunnel mode thing I was trying to do (where the ipsec tunnel carries 0.0.0.0/0 and encrypts all, then the router decides which packets to send over the tunnel) isn’t really possible with ROS [1] [2]. So I more closely followed the example using ipip + ipsec transport mode and finally got it working. Additionally I’ve got BGP routing on both ends, which does something similar to what I originally wanted with the tunnels.

I’ve still got a problem that the SAs only become fully established if the Cisco is the initiator. Otherwise for some reason it expects CONF_XAUTH username/password when MT is the initiator. Weird.

Also I still have to know ahead of time which networks I want to communicate beforehand with in the ip firewall nat configuration, which is kinda annoying.

But at least I’ve got it working.

[1] http://forum.mikrotik.com/t/route-outside-a-0-0-0-0-0-ipsec-tunnel/26391/1
[2] http://forum.mikrotik.com/t/cisco-827-to-mikrotik-ipsec-vpn-tunnel-issue/13212/2

Here’s my config for the record:

/interface ipip
add comment="" disabled=no local-address=221.221.XX.XX mtu=1460 name=ipip1 \
    remote-address=24.19.XX.XX
/ip address
add address=169.254.255.9/30 broadcast=169.254.255.11 comment="" disabled=no \
    interface=ipip1 network=169.254.255.10
/ip ipsec peer
add address=24.19.XX.XX/32:500 auth-method=pre-shared-key comment="" \
    dh-group=modp1024 disabled=no dpd-interval=30s dpd-maximum-failures=5 \
    enc-algorithm=aes-128 exchange-mode=main generate-policy=no \
    hash-algorithm=sha1 lifebytes=0 lifetime=1d nat-traversal=no \
    proposal-check=obey secret=SECRETKEY send-initial-contact=no
/ip ipsec policy
add action=encrypt comment="" disabled=no dst-address=24.19.XX.XX/32:any \
    ipsec-protocols=esp level=require priority=0 proposal=default protocol=\
    ip-encap sa-dst-address=24.19.XX.XX sa-src-address=221.221.XX.XX \
    src-address=221.221.XX.XX/32:any tunnel=no
/ip ipsec proposal
set default auth-algorithms=sha1 comment="" disabled=no enc-algorithms=\
    aes-128 lifetime=30m name=default pfs-group=modp1024



crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2
 lifetime 28800

crypto keyring keyring-qin 
  pre-shared-key address 221.221.XX.XX key SECRETKEY

crypto isakmp profile isakmp-qin
   keyring keyring-qin
   match identity address 221.221.XX.XX 255.255.255.255 

crypto ipsec transform-set ipsec-prop-qin esp-aes esp-sha-hmac 
 mode transport

crypto ipsec profile ipsec-qin
 set transform-set ipsec-prop-qin 
 set pfs group2

interface Tunnel4
 ip address 169.254.255.10 255.255.255.252
 ip virtual-reassembly
 tunnel source FastEthernet4
 tunnel destination 221.221.XX.XX
 tunnel mode ipip
 tunnel protection ipsec profile ipsec-qin