I’m a bit confused by xena@local.cz being used as both the common name of the initiator’s (Strongswan’s) certificate an the own ID of the responder (Mikrotik); maybe the IPsec stack is confused too? How does Mikrotik’s own certificate look like?
I also hazily remember I had cases where I had to remove the identity and set it up from scratch if changing the match-by value. So maybe try to do the same too, remove the identity and create it again, specifying just auth-method=digital-signature match-by=certificate remote-certificate=xena@local.cz certificate=vpn_ike2 mode-config=cfg1 peer=xena@local.cz generate-policy=port-strict policy-template-group=ike2 (i.e. don’t specify any my-id, which means it will be set to auto).
Another possibility might be that you’ve got multiple peers defined with exchange-mode=ike2 and the initial request is handled by another one than the one to which the identity row is linked. Unfortunately the log doesn’t show the peer chosen to handle the initial request.
Looking one step forward, if Subject-Alt-Name of Mikrotik’s own certificate doesn’t contain the IP address or fqdn to which the Strongswan connects, Strongswan will not consider that certificate valid - it ignores the contents of Common Name.
Yes, indeed, I have multiple peers defined with exchange-mode=ike2.
After I have disabled all peers except the one for android I can connect:)
But this raised 1 more questions:
AFTER I have established connection, I can ping from phone external sites (DNS resolves) but can’t connect to anything, no HTTP no HTTPS…
P.S. I was reading:
Release 6.48beta48
*) ike2 - added support for IKEv2 Message Fragmentation (RFC7383);
As my router is running 6.47.9, this could be the cause ( fragmentation) ?
RFC7383 only deals with application-level fragmentation of the control traffic (IKE), not of transport packets. Since the connection has established properly, this cannot be related.
I don’t understand why new-mss differs in the two rules, but more important, do these rules count? And is the firewall not blocking the TCP traffic?
The packets decapsulated from IPsec transport ones inherit the in-interface attribute from the transport ones. Assuming that ether1 is your WAN, the dst-nat rule action=dst-nat chain=dstnat in-interface=ether1 protocol=tcp to-addresses=192.168.50.10 to-ports=45000-45500
diverts any TCP connection coming in via ether1, no matter what the original destination port is, to a randomly chosen port between 45000-45500 at 192.168.50.1.
So add ipsec-policy=in,none to all the four dst-nat rules that don’t match on any dst-port value and you should be able to access http and https sites from the IKEv2 client. But the way these dst-nat rules look like now, I doubt they do what you actually want them to do - at least because the first one shadows the subsequent ones.
Waste of ammo… using a hammer provides more relief to your soul
Plus in your locality, you’ve got the globally unique possibility to get it run over by a šalina.
If that’s the goal, use dst-port=45000-45500 and dst-port=55000-55500, respectively, and remove to-ports.
The thing is that the parameters of the firewall rules fall into three groups:
the match conditions the packet must meet so that the rule matched
the action to be done if the rule matches
the parameters of the action - new values of some packet headers to be set, type of reject packet to be sent etc. depending on the particular action
So dst-port is a match condition, whereas to-ports is a parameter of the action (src-nat, dst-nat, netmap); maybe it should have been named new-ports instead, to avoid confusion with dst-port.
