I’ve got the following question:
When configure l2tp-client interface we’ve got a functions “use-ipsec”. It’s very usefull as it generate ipsec peer automatically and also gives me possibility to use DNS of central router to establish connection. But now our information security department make me use certificates instead of PSK. It looks like very simple change, but “use-ipsec” functions has restriction “Preshared key used when use-ipsec is enabled.”
If somebody knows how to avoid it?
You can uncheck use-ipsec under l2tp-client and configure IPsec manually as you wish. Use-ipsec option is there to simplify the configuration for most common setup type. You can copy IPsec policy and peer entries before unchecking use-ipsec option to make things easier for you.
Yes, please implement the possibility to define IPsec peers with “fqdn” instead of “peer address” (using exchange-mode “agressive”)
and the possibility to run a script when the association is established.
I use this on a plain Linux box to allow GRE/IPsec tunnels to clients with a dynamic address. The server listens for IPsec connections
from clients with the fqdn as the identifier, and when they come in they validate that clients PSK (each client has a different PSK),
and generate a phase2 policy (transport mode for GRE) for the address the client has at that time, and a GRE tunnel to that address,
from a script started at phase1 time. (by racoon)
This is currently impossible in MikroTik, as you can define client-specific IPsec peer definitions only for static addresses, and not by fqdn.
There also is no script hook to fix the GRE tunnel remote address.
v6.41rc11+ will have experimental support for FQDN as remote address for IPsec peers. FQDN support for IPsec policies not yet implemented. However, I am not sure how useful would the script callback be.
Well, as I mentioned, it is required for GRE/IPsec from a dynamic address, because the GRE tunnel has a “remote address” that you only know after the IPsec from that FQDN has established, so the script could be used to fix that up.
Note the FQDN is just an identifier string, it does not have to be in DNS neither does it have to refer to the actual address of the peer.
Now that I read this:
*) ipsec - allow to specify remote peer address as DNS name (CLI only);
… I am wondering if we are discussing the same thing! probably not.
FQDN support should be support for FQDN as identity in the peer definition, usable with exchange-mode “agressive”.
The FQDN field in the exchange is nothing more than a text field identifying the peer, and has nothing to do with FQDN used via DNS for remote address.
RouterOS supports it on client side (set “my ID type” to fqdn and enter “my ID”), but not yet for matching the remote ID in a peer definition without remote address.
I apologize for the confusion, I was never talking about using fqdn for remote peer’s identification, but using fqdn instead of IP address to specify remote peer’s address. At least I think that is what the original author of the topic was talking about.
Have you ever sent an e-mail to support asking for your mentioned features to be implemented?
No. I haven’t. I just brought it up because the topic was mentioned here and because I have installed a Linux system
that uses those features (with mostly MikroTik routers as clients) for GRE/IPsec tunnels from “dynamic” addresses (they change
maybe 2 times a year) and it would be possible to migrate this to a CCR we have at that location when this feature would
be available. In the meantime, I am considering using L2TP/IPsec instead.
any update on this issue? On SSTP server we can veritfy client certificate. Is it possible to implement same for L2TP server? Seems like relatively simple thing to do, but maybe I am mistaken.