I have an RB2011 where I need to establish two IPsec connections:

ether5 --- static site
ether2 --- dynamic clients (road warrior)

The peer configurations for these are:
0 address=0.0.0.0/0 passive=yes port=500 auth-method=pre-shared-key
exchange-mode=main-l2tp send-initial-contact=no nat-traversal=yes
hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp2048 lifetime=1d

1 address=10.28.1.3/32 passive=no port=500 auth-method=pre-shared-key
send-initial-contact=yes nat-traversal=no proposal-check=claim
hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1h
[some config entries omitted, e.g. psk!]

and the proposals:

0 * name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-128
lifetime=30m pfs-group=modp1024

1 name="vpn_site1" auth-algorithms=sha1 enc-algorithms=aes-128,aes-256
lifetime=30m pfs-group=modp2048

What I've found is that the site-site IPsec (peer and proposal 1) gets established OK but the "road warrior" configuration fails. The logs show "no suitable proposal" but appear to also show a mismatch between peers in the "DB:peer" ipsec debug logs. The mismatch occurs because the wrong peer is being used (you can see the difference in the encryption and dh-group settings.)

The client side (Linux + openswan + xl2tp) shows that there's no response from the phase 1 negotiation. This is consistent with the RB2011 rejecting the request due to a mismatch. To test whether this was occuring I disabled peer 1. Having done this it obviously drops the established connection with the remote site but then the road-warrior client was able to connect to the RB2011 and phase 1 and 2 IKE completed successfully. This test seems to suggest one of two possibilities:

a) The wrong peer is being selected, seemingly ignoring the address and subnet configurations
b) The presence of an established IPsec tunnel to the remote site (on ether5) is somehow interfering with the "road warrior" L2TP/IPsec connection on ether2.

I'd be grateful to anyone who can shed some light on what might be going on here with this apparent conflict.

It seems the VPN in Router OS v6.12 has bugs issues...could relate to number 3 in the link below.

http://forum.mikrotik.com/viewtopic.php?f=2&t=78816

Thanks for the suggestion but I don't think these cases are related. I've only got one IP address on the interface in question. It seems to be the wrong peer that's selected. According to the manual, the peer to use is decided by matching the source IP address. The logs seem to suggest the fixed IP address peer is being tested rather than the open one (0.0.0.0/0). It's possible that the logs simply show 'failed matches', but this would be rather odd.

What is clear is that if I disable the other peer configuration (for the static site-to-site VPN connection on a different interface) the inbound VPN establishes straight away.