To me, the mysterious part was the link between the L2TP authentication and IPsec authentication, but it seemed to me that you’ve already got past that.
When you check the “use IPsec” in L2TP client configuration, both an IPsec peer and an IPsec policy are created “dynamically”. The dynamically created policy:
- is a “real” policy, not a template,
- matches UDP traffic from port 1701 at the IP address which is the best-fitting local source for the route towards the “server” to port 1701 at the IP address of the “server”,
- and requires use of ESP in transport, not tunnel, mode. So it only encrypts and encapsulates the L2TP transport packets.
The generic (i.e. not L2TP/IPsec specific) policy template on the server side is open so widely that a mirror policy to the above one can be generated from it. The peer has an exchange mode “main-l2tp”, which is an important point.
When you check the “use IPsec” in L2TP server configuration, a “dynamic” IPsec peer is generated as well, with policy-generate mode set to “port strict”, choosing from policy template group “default”, and with authentication mode “main-l2tp” as well.
The manual says:
main-l2tp > mode relaxes rfc2409 section 5.4, to allow pre-shared-key authentication in main mode.
I’m also not sure what that means in detail, but the outcome is that a match of the pre-shared key between the peers (and intersection of IPsec proposals of course) is the only prerequisite necessary to establish an IPsec SA between such peers. No additional authentication is necessary.
To check this, you may
- disable all the peers and policies you’ve created manually and keep only the default ones
- activate an L2TP server with use-ipsec=true and a pre-shared secret at the server side, and create an L2TP client interface with corresponding settings at the client side
- do ****
/ip ipsec peer add copy-from=[find exchange-mode="main-l2tp"] disabled=yes
at both the server machine (at any time) and the client machine (while the L2TP connection establishment attempt is running
/ip ipsec policy add copy-from=[find src-port=1701] disabled=yes
at the client machine while the L2TP connection establishment attempt is running
- disable the L2TP server and the L2TP client interface, and enable the cloned peers and policies.
At this moment, you should see two SAs established.
And this is the moment when, in the “normal” case where these peers and policies are dynamically created and activated by the L2TP/IPsec astro clock, the L2TP client starts establishing its conection to the server. If the attempt doesn’t succeed within timeout, the client side removes the dynamic peer and policy and starts the whole procedure again.
So to summarize: in the L2TP/IPsec “bundle”, the IPSec is only used to encapsulate and encrypt the connection between the L2TP client and the L2TP server. All the rest (authentication of the L2TP client, choice of the address to be assigned to the client based on its user name, its assignment to the virtual interface at client side, delivery of default route etc.) are the job of L2TP, And the operation of the L2TP part is identical regardless whether the packets between client:1701 and server:1701 run via IPsec SAs or directly.
By decoupling the IPsec layer from the L2TP, which consists in unchecking the “use IPsec” in L2TP configuration and configuring IPsec peers and client side policy manually or using a script if the client’s address changes, you can choose different encrytptions and authentication algorithms, but you must not change the “main-l2tp” exchange mode, and you effectively cannot use rsa-key mode because exactly one remote key must be indicated.
If you use IPsec xauth, the user name and password are used to authorize the user and eventually choose a particular client-side IP address for him already at IPsec level. At server side, the necessary user name and password are configured in the ****
/ip ipsec user
branch rather that the
/ppp secret
one. The IP settings are delivered to the client using the mode-config mechanism, and the address is not assigned to an eventually existing L2TP interface at client side (about which the IPsec layer knows noting at all). The mode-config mechanism attaches the IP address as a secondary one to a seemingly randomly chosen local interface of the client and creates the policy (or multiple policies if “split include” is configured) referring to this address at client side.
xauth can only be used together with pre-shared key, rsa-signature (the mode is called rsa-signature-hybrid) and IKEv2 modes. rsa-key mode does not permit a wildcard for the remote key and it is impossible to have the same rsa key at all clients as the private part of it must always be generated locally.
To use L2TP over IPsec with xauth is possible but it is a kind of an overkill, plus you need two user names and two passwords (which may be identical but need to be configured at two places per connection side) and two IP addresses (which must differ) per client to make it work.
However, although the mode-config settings at both ends mention an address prefix size, and the IP settings at client side respect that, the generated policies don’t. This may be a bug of the versions used (6.41.1 at server side and 6.42rc49 at client) or an intention, I don’t know.
