I’ working on a solution with a hub-spoke setup interconnecting with ipsec.
I would like to run with certificates,- but PSK could be ok.
So far I’ve been unable to produce a working configuration, if a spoke have a DHCP assigned WAN ip address.
I’ve been testing and trying, reading a lot of documentation and instructions,- but so far, I haven’t found found a working solution.
To me,- not being the world greatest ipsec/certificate master,- it stuns me,- it’s possible to create encrypted tunnels, without static WAN ip, with OpenVPN?
Am I misunderstanding something, does any have a working configuration with ipsec tunnels between a HUB with static WAN ip and dynamic assigned ip on SPOKES?
PSK or certificates.
The title says IPsec, the body says OpenVPN. Which one you actually want? I know for sure that IKEv2 with certificate authentication does work beacuse I use it; I know that OpenVPN should work the same way but I don’t use OpenVPN on Mikrotik due to the limits of Mikrotik’s implementation.
Oh,- I want ipsec,- I just mentioned OpenVPN because of it’s ability to connect using DHCP assigned ip address.
I haven’t been able to find/compose a configuration making ipsec connect. I thought I tried every possible configuration
Hub → static WAN ip
Spokes → DHCP assigned WAN ip addresses
Can you link to working configuration, I must be failing somewhere. I’ve spend some weeks now
So far I’ve used self-signed certificates and CA created on the HUB.
Input chain of /ip firewall filter must permit incoming connections to UDP port 4500 from clients; if clients’ WAN addresses are public ones, also ESP must be permitted in the same chain, at both clients and the hub.
I’m not sure regarding self-signed certificates. If they are not accepted, follow my setup: on clients I only have the public certificate of the signing CA of the server’s certificate and the private certificate of the client (which happens to be signed by the same CA so if these two CAs differ in your case, it is probably necessary to have both installed, one to verify the server certificate (this is for sure) and the other one to be (possibly - not sure here) sent along with the client’s certificate itself); on the server, I have the CA certificate (the public certificate of each CA signing one or more client certificates is necessary), the private certificate of the server, and the public certificates of the clients as they are used in /ip ipsec identity to identify the clients.
This way (match-by=certificate), the common name of the certificate may be basically any distinctive string. I believe you could use some distinct fqdn-like strings something.something[.something] as client certificates’ common names, and set the identities at server side to match-by=remote-id remote-id=fqdn:client’s.fqdn.used.as.cert.common-name, and set my-id at client side to fqdn:client’s.fqdn.used.as.cert.common-name, i.e. I believe no DNS query is sent to check that the fqdn sent by the client resolves to client’s actual IP address.
