Hi Everyone,
I need help in circumventing problem i encountered trying to configure IPsec/IKEv2 VPN
here is the topology
vIOS router simulates Internet clients Linux and LClient2 are connecting using StrongSwan IPsec/IKEv2 with certificates
If I specify peers adresses for clients everything works fine, also everything is fine if only one’s peer srcaddr is is ::/0
This configuration would obviously be impractical as normally i would not know the addresses of clients, but the moment i set both peer addresses to any ::/0 i get only one connection working and other client gets
it looks to me like router is unable to uniquly identify client’s connections despite using client’s certificates ? What can I do to make it working ?
Use just a single /ip ipsec peer row with address=::/0 and link both the /ip ipsec identity rows to it. That’s how it is intended to work, and that’s why the identity parameters are located in a separate table.
You Sir are a gentleman and a scholar, I’ve already tried that earlier but I was misled by some errors about not being able to assign another certificate to peer or something, so I gave up on that. I scrapped the tunnels and build it again and it works like a charm. Thank you for quick answer. But … now another challenge arise, the green ones work but how do you route the red one without interface? I would belive it is in policies ? I’m lost, could you shed some light on it or point me to some materials as I didnt find anything regarding MikroTik in this scenario.
I’m aware that using maybe SSTP/SSL or openVPN for clients in this scenario would be preferable.
I don’t understand the meaning of the green and red lines.
The diagram shows a butterfly topology, so are the road warrior clients running Strongswan supposed to be connected to both Mikrotik routers simultaneously, and the IPsec connection to the bottom Mikrotik doesn’t work?
My automatic signature (“instead of writing novels”) refers to description of device configuration in plain words rather than posting it in the form of an export; a description of the required goal and the actual result in plain words is necessary, though.
Sorry, my goal is to get connectivity for road warriors to other part of site-to-site tunnel from their ipsec subnet 172.32.0.0/24 to 172.16.0.0/24
at present moment
linux5 can communicate with linux4 over site-to-site
road wariors can communicate in their subnet 172.32.0.0/24
road wariors can communicate with linux5 over their tunnels
The traffic selector of the policy on the site-to-site IPsec link chooses just the traffic between 10.16.0.0/24 and 172.16.0.0/24, whereas you assign addresses from 172.32.0.0/x (do you realize that 172.32.0.0/16 is not a private range?) to the dial-in clients.
So you need to add another policy to the site-to-site link, where 172.32.0.16/29 will replace the 10.16.0.0/24.
yes I do realize that 172.32.0.0 is not private range, I just got carried away with round numbers - as its just a lab but i fixed it. I got it working eventually, but i wanted to ask you where did the 172.32.0.16/29 came from ? it is not even in dhcp range for my clients or did you assume that as it’s public it’s better to cut off less public address from clients but if so why not 172.32.0.16/30 ? anyway this is what is bare bone needed for this scenario to work both directions:
unfortunatly i dont quite get what going on in that NAT part
172.32.0.16/29 is .16 to .24, so it includes .19 and .20.
172.32.0.16/30 would be just .16 to .19 so .20 wouldn’t fit.
And yes, the intention was to suggest the smallest (longest) prefix that includes addresses of both the test clients. You keep posting screenshots rather than text export, so a lot of information is missing and the efficiency is low (much less information about configuration per square inch of the screen).
The packets for delivery via IPsec SAs are chosen after all the firewall processing, including NAT, has been finished. So if you don’t exclude the traffic between traffic selectors’ source and destination subnets from getting src-nated, it will get src-nated and thus the traffic selectors will miss it.
But you can do it in a simpler way, add ipsec-policy=out,none to the match condition list of the action=src-nat (or action=masquerade) rule. This match condition matches on all packets that do not match any existing traffic selector, so you don’t need to add an individual action=accept rule for each traffic selector. So you don’t need to configure the same data at multiple places.
Very insightfull.Thank you for your help