I'm triying to set a Client to Site VPN from my Mikrotik RB, of type pre-shared-key-xauth; I've already set Preshared Key, User and password, but there's an xtra parameter GroupName.

Is there any way to set this kind of pre-shared-key-xauth with a GroupName in configuration

Kind Regards

Looks like it’s not possible, even with “pure” IPSec XAuth nor L2TP/IPSec, unfortunately.
IPSec’s implementation is vendor-specific and MT’s version don’t have “group name” parameter, so leave it blank on client side, or it will not work.

Also, it’s impossible to set ipsec identities with different shared secrets on same peer, and if you setting up Road Warrior scheme (with ip-undefined remote users and MT as responder) you have 1 “universal” peer with address ::/0, so, you can’t set different secrets for grouping remote peers

Two peers with same address and parameters, but different name will work strange, depends on position in list, so don’t do it, it will not solve problem:)

But you still can group users and control user access through routing and filtering in firewall (and mode-config in fine-tuned ipsec part of remote access scheme).

I hope in ros7 grouping vpn peers will be implemented.

Tech-heads, please tell me, if I wrong:) Peace)

Sorry for my bad English, trying without google translate:)

it’s impossible to set ipsec identities with different shared secrets on same peer, and if you setting up Road Warrior scheme (with ip-undefined remote users and MT as responder) you have 1 “universal” peer with address ::/0, so, you can’t set different secrets for grouping remote peers

The above used to be true but it isn't any more. Currently (6.44+), you can distinguish the remote initiator peers by the protocol field called "identity", not just by the IP address from which (or from behind which) they connect, and for each such identity, you can configure a dedicated pre-shared key and mode-config line - all that on a single peer. What remains true is that there is no group identity - it is up to you whether you assign several identities the same pre-shared key value and/or the same mode-config profile referring to the same /ip pool.

it’s impossible to set ipsec identities with different shared secrets on same peer, and if you setting up Road Warrior scheme (with ip-undefined remote users and MT as responder) you have 1 “universal” peer with address ::/0, so, you can’t set different secrets for grouping remote peers

The above used to be true but it isn't any more. Currently (6.44+), you can distinguish the remote initiator peers by the protocol field called "identity", not just by the IP address from which (or from behind which) they connect, and for each such identity, you can configure a dedicated pre-shared key and mode-config line - all that on a single peer. What remains true is that there is no group identity - it is up to you whether you assign several identities the same pre-shared key value and/or the same mode-config profile referring to the same /ip pool.

Thank you for correction.
I don’t fully understand how it work.
Does it work with PSK and XAUTH PSK?
For example, I need 2 remote access peers with different secrets, but same security level. To do it I set 1 peer with address ::/0, then in /ip ipsec identity I set 2 id’s with different shared secrets - and this isn’t work: with psk (for l2tp/ipsec) ROS says “same peer already exist”, with xauth ROS says “can’t use different secret”. It can be fixed by manually setting my-id and remote-id fields, but I don’t understand how set it on client-side (macos and win). Please tell, what I’m doing wrong? (I’m a little bit of lamer:))

When using L2TP over IPsec, you don't need to do too much at IPsec level, as a single PSK common for all users is sufficient (if we leave aside the security considerations). The hierarchy of ppp profiles and their rich feature set can be used to arrange user accounts (/ppp secret items) into groups. By means of /ppp profile, you can assign each account's IP address to an /ip firewall address-list of your choice, and/or you can add each account's dynamically created interface to an /interface list of your choice.

Further reading: viewtopic.php?t=149174#p734404

With IKEv2 on Windows, you currently have to use a machine certificate anyway if you want to use the Windows' native VPN client, and the certificate alone can be used to choose the /ip ipsec identity row (using match-by=certificate); each /ip ipsec identity row then can refer to an /ip ipsec mode-config row, which further refers to an address-pool to be used for clients which get their settings by means of that mode-config row; your specific firewall rules per group of users then have to match on the address ranges (address pools). The advantage of IKEv2 as compared to L2TP is that you can send the Windows clients a list of subnets to access via the VPN.

As for iOS, I have no idea what parameters for IKEv2 can be set in the native VPN client.

As stated here, EAP client authentication with no need for an external RADIUS server seems to be in the tunnel, so in a couple of months we might see individualized settings to be configured by means of the on-board User Manager.

It’s a pity that professional MT doesn’t do the same thing that home zyxel keenetic can do (although it has huge problems in implementing ikev2) or xiaomi. I really need different shared secrets, because groups of remote users should not know absolutely nothing about each other. Then the best option is to abandon ikev1 completely in favor of ikev2. Thanks again for the detailed explanations.

set this
my-id=key-id
my-id=groupID

@td32, I assume you had in mind to set, in the /ip ipsec identity row at the Mikrotik serving as initiator (client), my-id=key-id:the-group-ID. So this addresses the OP.

Do you also have an idea how to make the embedded Windows client use the groupID in L2TP/IPsec mode as @Normie requires?

on windows only by using the cisco client vpn utility
i dont think windows supports it natively

set this
my-id=key-id
my-id=groupID

Thanks, will try. It may be solution for mac clients.
For win-clients you right - windows embedded l2tp/ipsec client not working with tunnel groups, sad but true.

It's time to switch to ikev2

@td32, I assume you had in mind to set, in the /ip ipsec identity row at the Mikrotik serving as initiator (client), my-id=key-id:the-group-ID. So this addresses the OP.

Do you also have an idea how to make the embedded Windows client use the groupID in L2TP/IPsec mode as @Normie requires?

Did you mean that row will not work if MT acting as responder?

Did you mean that row will not work if MT acting as responder?

Yes, that's what I had in mind. The value of my-id is used as the ID the local peer sends to the remote one to identify itself, the values of remote-id of the individual identity rows are matched to the ID provided by the remote peer in order to choose the proper identity row to source the other parameters from. So the initiator has one identity row per peer row (as it is the peer, not the identity, what holds the address of the remote peer to send the initial request to), whereas the responder may have many identities linked to a single peer, among which it chooses the right one based on the received ID as described above.

Did you mean that row will not work if MT acting as responder?

Yes, that's what I had in mind. The value of my-id is used as the ID the local peer sends to the remote one to identify itself, the values of remote-id of the individual identity rows are matched to the ID provided by the remote peer in order to choose the proper identity row to source the other parameters from. So the initiator has one identity row per peer row (as it is the peer, not the identity, what holds the address of the remote peer to send the initial request to), whereas the responder may have many identities linked to a single peer, among which it chooses the right one based on the received ID as described above.

Thank you very much, this part has become much clearer.

I ask for help to configure Cisco IPsec (Mac OS terminology). As I understand it, this authentication method is called "pre shared key xauth", i have only following data:

IPSec Gateway <IP Adress>
IPSec ID <GroupName>
IPSec Secret <Secret>
Xauth Username <UName>
Xauth Password <PW>

IPSec Gateway <IP Adress>
IPSec ID <GroupName>
IPSec Secret <Secret>
Xauth Username <UName>
Xauth Password <PW>

/ip ipsec peer add name=some-peer exchange-mode=main address=<IP Address>
/ip ipsec identity add peer=some-peer my-id=key-id:<GroupName> mode-config=request-only generate-policy=port-strict auth-method=pre-shared-key-xauth secret=<Secret> xauth-login=<UName> xauth-password=<PW>

But you'll probably have to spend some time on /ip ipsec profile and /ip ipsec proposal to match those supported by the Cisco responder.

/ip ipsec peer add name=some-peer exchange-mode=main address=<IP Address>
/ip ipsec identity add peer=some-peer my-id=key-id:<GroupName> mode-config=request-only generate-policy=port-strict auth-method=pre-shared-key-xauth secret=<Secret> xauth-login=<UName> xauth-password=<PW>

But you'll probably have to spend some time on /ip ipsec profile and /ip ipsec proposal to match those supported by the Cisco responder.

Yes, i've connected!
I have these generated policies and what i have to do now? I can't ping any host, traceroute does not work.

2 T 0.0.0.0/0 0.0.0.0/0 all
3 DA Flashels yes 172.27.0.122/32 172.16.0.0/12 all encrypt unique 2
4 DA Flashels yes 172.27.0.122/32 10.7.0.0/16 all encrypt unique 1
5 DA Flashels yes 172.27.0.122/32 10.8.0.0/16 all encrypt unique 1
6 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
7 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
8 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
9 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
10 DA Flashels yes 172.27.0.122/32 10.10.222.0/24 all encrypt unique 1
11 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
12 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
13 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
14 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
15 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
16 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
17 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
18 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
19 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
20 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
21 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
22 DA Flashels yes 172.27.0.122/32 all encrypt unique 1
23 DA Flashels yes 172.27.0.122/32 all encrypt unique 1