MikroTik

Posted: **Wed Feb 05, 2025 1:00 pm**

Hello,

i'm quite new to MikroTik.
Upto now: i did build a site-2-site IKEv2 tunnel with routing between networks, took some effort but works great now.
So i thought i'd use the same router (HexS) to create IKEv2 connection for remote clients.
I did study docs and forum a lot, the following was the resulting idea :
- MikroTik IPsec/IKEv2 behind a NAT-router/fw
- Radius server on the MikroTik on 127.0.0.1 to get the 2FA/MFA working (timebased authenticator app)
- Windows native VPN client via PowerShell config

But, .... after some weeks of learning and experimenting ...
I am rather stuck. Too many problems at once, too many variables, too little logging to tell me what is wrong.
I excluded the 2FA/MFA problem for now.
The router and the client both are internal networks. The forwarding (NAT) works.

The windows client needs certificates. Cant get that right. Help ?
I cannot seem to get much log (ipsec) from the MikroTik nor from the windows client. Anyone ?
Any ideas or config-examples ?
Any help would be greatly appreciated!

Posted: **Wed Feb 05, 2025 2:36 pm**

Certificate: the IPsec responder has to present the complete certificate chain that starts with its own certificate and contains any intermediate certificates all the way to the root CA - the certificate item on the /ip/ipsec/identity row is actually a list. The Windows machine acting as an IKEv2 initiator must have the root CA certificate in its "trusted CAs" store. The own certificate of the responder must contain the FQDN or the public address to which the Windows initiator connect in the SubjectAlternateNames list - CommonName is not enough. The key type (RSA/ECDSA) must match the ciphers used for DH, so only use ECDSA if you need that and know excactly what you are doing.

In practical terms, one way is to use Let's Encrypt or other public authority to issue the own certificate for the responder, because then you don't need to install anything on the Windows clients - the root CA certificate is distributed using Windows Update in this case. Another way is to use your own certification authority to issue the own certificate of the responder, but if you take this way, you must install the certificate of that CA to all the Windows clients into the trusted CA store.

For L2TP/IPsec, Windows by default do not accept a responder running on a private address, I have never tried whether it is the case also for IKEv2 responders. For a few clients or if centralized management is available, you can resolve this by modifying the registry; if that's too complicated, a trick exists that makes the responder behave as if it was running on a public address although it is actually behind a NAT.

To see more in the ipsec logs on Mikrotik, issue the following command:
/system/logging/add topics=ipsec,!packet

As you already use some IKEv2 config, there may be conflicts that need to be resolved, so what does /ip/ipsec/export show right now? Obfuscate any my-id and remote-id items on the /ip/ipsec/identity rows before posting.

Posted: **Wed Feb 05, 2025 2:49 pm**

Hi,

for certificates only you can use this tutorial:
https://help.mikrotik.com/docs/spaces/R ... entication

for cert + user/pass this tutorial:
https://help.mikrotik.com/docs/spaces/R ... outerOSv7)

MFA is quite a bit complicated but it can be done using second method with UserMan..
Under user there is OTP Secret and you can create BASE-32 Secret and then use an Authentificator (Gogle Auth) to add this layer of additional security...

Posted: **Wed Feb 05, 2025 8:49 pm**

@hunter : those are exactly the sections i used to get started with it, but i cant get it working yet.
I have read the MFA authenticator/user-manager/radius but since i already have to much troubles i will leave that for later.
https://help.mikrotik.com/docs/spaces/R ... Suserlogin

@sindy : i tried many, the own-ca way.

 0 K A T local-cert         local-cert                               
 1 K A T webfig             10.0.x.xxx                               
 2 KLA T ca                 ca                                       
 3 K  I  TesTikDE           10.0.x.xxx             IP:10.0.x.xxx     
 4 K  I  TestFlap           TestFlap                                 
 5 K  R  TesTikDE_outside   80.aaa.bbb.cc          IP:80.aaa.bbb.cc  
 6 K  R  TesTikDE_dns       myname.ourdomain.de                      
 7 KLA T ca_outside         ca_outside                               
 8 KLA T ca_dns             ca_dns                                   
 9 K  I  TesTikDE_outside2  80.aaa.bbb.cc          IP:80.aaa.bbb.cc  
10 K  I  TesTikDE_dns2      myname.ourdomain.de

I did not try lets-encrypt yet, i will try that, it might solve problems with windows-importing (used the automatic-which-store...) i'm a little confused there.
Regarding the cyphers: No, i do not know exactly what i'm doing

too many options...

Interested in what u mean by the behind-NAT-trick. I'm using 500/4500 nat-traversal now.

Logging: had topcis=ipsec,packet and tried topcis=ipsec also.
Changed it to ipsec,!packet See if thats better Thanx.

Export: (might be a mess, i tried too may things, need to clear it and start over i think)

# 2025-02-05 19:23:02 by RouterOS 7.16.2
# software id = GKW7-GIGP
# model = RB760iGS
/ip ipsec mode-config
add address-pool=TSDE_vpnpool address-prefix-length=32 name=ike2-conf
/ip ipsec policy group
add name=ike2-policies
/ip ipsec profile
set [ find default=yes ] dh-group=x25519,ecp384,ecp521 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512 proposal-check=strict
add dh-group=x25519,ecp256,ecp384,ecp521,modp8192,modp6144,modp4096,modp3072,modp2048 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=TStest_IKEv2_ph1
/ip ipsec peer
add exchange-mode=ike2 name=peer1 passive=yes profile=TStest_IKEv2_ph1
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha512,sha256 disabled=yes enc-algorithms=chacha20poly1305,aes-256-cbc,aes-256-gcm pfs-group=ecp521
add auth-algorithms=sha512,sha256 enc-algorithms=chacha20poly1305,aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-gcm name=TStest_IKEv2_ph2 pfs-group=none
/ip ipsec identity
add auth-method=digital-signature certificate=TesTikDE_dns generate-policy=port-strict match-by=certificate mode-config=ike2-conf peer=peer1 policy-template-group=ike2-policies remote-certificate=TestFlap remote-id=ignore
/ip ipsec policy
set 0 disabled=yes
add dst-address=10.0.x.0/24 group=ike2-policies proposal=TStest_IKEv2_ph2 src-address=0.0.0.0/0 template=yes

Yes, it is a mess now.. Sorry.

The server authentication is not very important, it is a situation where a handfull of capable staff need remote access to the companies servers &| network.
I had in mind to start with PSK-only but that didnt turn out to be so easy...

Question:
Keeping in mind that i want the radius-method later for MFA/Authenticator, which auth-method should i choose now (w/o radius) on both sides, to start with ?
A simple config (to start with) would be great. I need less options too choose from...

Posted: **Wed Feb 05, 2025 8:56 pm**

<double>. Tried to delete but didnt work.

Posted: **Wed Feb 05, 2025 10:20 pm**

Interested in what u mean by the behind-NAT-trick. I'm using 500/4500 nat-traversal now.

The ability to use ESP encapsulation into UDP and related stuff to traverse NAT is a capability of IPsec as a protocol; not accepting a responder behind NAT is a default behavior of the Windows embedded VPN client (at least in the L2TP/IPsec mode) that can be changed.

The trick consists in assigning the public address of the NAT device (to which the initiators connect) as a /32 one to some interface of the Mikrotik (ideally, and empty bridge) and creating a dst-nat rule that forwards UDP ports 500 and 4500 on the private WAN address of the Mikrotik to that public address (so you "compensate" the external NAT). That way, the NAT detection of IPsec only identifies the presence of NAT at the initiator side. The downside is that this trick breaks the NAT detection if the initiator is not behind a NAT, so if that may happen, it can only be used if the external NAT device at the responder side can be told to forward any incoming bare ESP traffic to the WAN IP of the Mikrotik.

The server authentication is not very important

It is. Without the ability of the initiator to verify that it is connecting to the correct server, a MITM or an impersonator could harvest the usernames and passwords.

I had in mind to start with PSK-only but that didnt turn out to be so easy...

Except RouterOS and Strongswan, I haven't seen any IKEv2 implementation yet that would support PSK.

which auth-method should i choose now (w/o radius) on both sides, to start with ?

The embedded client of Windows has just two possibilities:

authenticate itself to the server using a machine (not user) certificate, which cannot be "unlocked" per connection using a passphrase to the private key, so a stolen machine can connect (i.e. the only obstacle is the password to the Windows account)
authenticate itself using username and password; in combination with the dynamically generated TOTP suffix to the password, it seems safer to me than the previous method. But a RADIUS server at responder side is mandatory for this method.

A working configuration follows:
/ip ipsec mode-config
add name=windows split-include=172.18.0.0/22
/ip ipsec policy group
add name=win-default
/ip ipsec profile
add dh-group=modp1024 dpd-interval=30s enc-algorithm=aes-256 hash-algorithm=sha256 name=windows
/ip ipsec peer
add exchange-mode=ike2 local-address=pub.lic.wan.ip name=ike2-responder passive=yes profile=windows send-initial-contact=no
/ip ipsec proposal
add name=windows-default pfs-group=none
/ip ipsec identity
add auth-method=eap-radius certificate=letsencrypt-autogen_2025-01-03T23:38:06Z,LetsEncryptR10 generate-policy=port-strict mode-config=windows peer=ike2-responder policy-template-group=win-default
/ip ipsec policy
add group=win-default proposal=windows-default template=yes

/user-manager router
add address=127.0.0.1 name=local

/radius
add address=127.0.0.1 called-id=pub.lic.wan.ip service=ipsec

I hope I haven't forgotten any important bit when copy-pasting.

Posted: **Thu Feb 06, 2025 9:05 pm**

Except RouterOS and Strongswan, I haven't seen any IKEv2 implementation yet that would support PSK.

Just as a little factoid, I have IKEv2 with PSK authentication working between RouterOS and a Fortigate.
https://docs.fortinet.com/document/fort ... rtificates
I'd assume Forti uses an inhouse IPsec engine, not Strongswan?

Posted: **Thu Feb 06, 2025 9:56 pm**

Except RouterOS and Strongswan, I haven't seen any IKEv2 implementation yet that would support PSK.
Just as a little factoid

...and this, kids, is what happens when you lose concentration when posting

What I actually wanted to say was that I haven't seen any other kind of VPN client on a PC or phone that would support PSK along with IKEv2 except Strongswan (and even Strongswan for Android does not support that), then started thinking about the rumours that RouterOS uses Strongswan internally, and ended up posting a total nonsense. Of course not only Fortinet but also Cisco and other router brands do support IKEv2 with PSK.

Posted: **Thu Feb 06, 2025 10:16 pm**

 0 K A T local-cert         local-cert                               
 1 K A T webfig             10.0.x.xxx                               
 2 KLA T ca                 ca                                       
 3 K  I  TesTikDE           10.0.x.xxx             IP:10.0.x.xxx     
 ......

I would delete the CA and all certificates will be gone too..
Then create new ones:

/certificate
add common-name=CA name=CA key-size=4096 days-valid=3650
sign CA ca-crl-host=remote.somewhere.at
add common-name=1.2.3.4 subject-alt-name=DNS:remote.somewhere.at key-size=4096 key-usage=tls-server name=MyVPN days-valid=800
sign MyVPN ca=CA
add common-name=User1 subject-alt-name=DNS:User.Company key-size=4096 key-usage=tls-client name=User1 days-valid=800
sign User1 ca=CA

common-name=YourPublicIP
SAN=dns name

For IOS devices I had problem If I user the same CN and SAN. Or just CN... So I made SAN like this..

Client on computer needs: CA Public Key and User Public And Private.
All need to be imported into LocalMachine!

use the lines provided by Sindy and for certificates only change this:

/ip ipsec identity
add auth-method=digital-signature certificate=MyVPN,CA generate-policy=port-strict mode-config=ike2-conf peer=ike2 policy-template-group=ike2-policies

This is cert Only (no MFA possible).
If you need MFA You can use LetsEncrypt cert as Sindy .. or your certificates created above..
If you use LE cert no need to import anything on client! Just user+pass set in UserManager...
MFA works as decribed on the help page you linked!

Posted: **Wed Feb 12, 2025 3:50 pm**

Ok! Thanx for all the input.
Was away a bit, had to spend time on other things, but am back on it now.

(intermezzo:
1/ I already had a working PSK-VPN from another MikroTik, to a Cisco machine. Built that ~2 months ago, the MikroTik side that is.
2/ I need MFA later so i did go for what Sindy advices.)

I now have a working LetsEncrypt certificate on the new Mikrotik, that sits behind a quite standard DSL-modem/router.
The dsl-public address (80.153.x.y) has a real dns name, within our own domain, the MikroTik itself has an internal 10.0.a.b address.

I have created the fake WAN bridge with external address and dstnat-rule, but the MikroTik doesnt seem to need that for the automatic/ACME certificate-issuing.
That works, with a filtered port 80 forward thru the dsl-router, with or without the fake interface
I disabled it for now, can re-enable it later when needed for the VPN.

Starting work on the VPN now.

Posted: **Wed Feb 12, 2025 4:31 pm**

It seems to work partially ..
I see more logging, thats good.

What worries: no IKEv2 peer config for <client.pub.lic.ip>

Posted: **Wed Feb 12, 2025 4:48 pm**

I removed the local-address=pub.lic.wan.ip from the ipsec peer ike2-responder, that works now.
I added ecp384 to the dhgroups of the 'windows' phase1 proposal. I think that is a remainder of a Set-VPN... PS-command that i configured the windows-client with.

Next problem:
identity not found for peer: ADDR4: 192.168.179.7

That is the client's wifi-local address. The client also sits behind its own dsl-router that providers it with a wifi connection.

ideas ?

i'll go read the windows client config stuff again...
https://docs.netgate.com/pfsense/en/lat ... ndows.html
https://learn.microsoft.com/en-us/power ... ver2025-ps
https://learn.microsoft.com/en-us/windo ... /vpn-guide

Posted: **Wed Feb 12, 2025 5:50 pm**

...
There was a warning "peer does not exist" above indentity that contains ike2-reponder visible in webfig.
I open it, clicked the dropdownlist and chose the "ike2-reponder" again, clicked 'OK' and now its gone...
The problem has changed also now.
The "identity not found for peer: ADDR4: 192.168.179.7" is gone now.

But now, after entering username an password as defined in the /user-manager/user, the windows client says that the IKE-auth. references are unacceptable
I have seen that before.

Posted: **Wed Feb 12, 2025 6:01 pm**

Does the log show that IPsec sends a query to RADIUS?

Posted: **Wed Feb 12, 2025 6:16 pm**

there is no mention of radius in the log
I was looking into EKU right now

Posted: **Wed Feb 12, 2025 6:23 pm**

/ip ipsec mode-config
add address-pool=MY_vpnpool address-prefix-length=32 name=ike2-conf
add name=windows split-include=10.x.x.x/24
/ip ipsec policy group
add name=ike2-policies
add name=win-default
/ip ipsec profile
set [ find default=yes ] dh-group=x25519,ecp384,ecp521 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha512 prf-algorithm=sha512 proposal-check=strict
add dh-group=ecp384,modp1024 dpd-interval=30s enc-algorithm=aes-256 hash-algorithm=sha256 name=windows
/ip ipsec peer
add exchange-mode=ike2 name=ike2-responder passive=yes profile=windows send-initial-contact=no
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha512,sha256 disabled=yes enc-algorithms=chacha20poly1305,aes-256-cbc,aes-256-gcm pfs-group=ecp521
add auth-algorithms=sha512,sha256 disabled=yes enc-algorithms=chacha20poly1305,aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-gcm name=PreviousTEST_ph2 pfs-group=none
add name=windows-default pfs-group=none
/ip ipsec identity
add auth-method=eap-radius certificate=my.dnsname.com generate-policy=port-strict mode-config=windows peer=ike2-responder policy-template-group=win-default
/ip ipsec policy
set 0 disabled=yes
add group=win-default proposal=windows-default template=yes

The windows-client was using EAP-TTLS, changed that to EAP-MSCHAPv2 which did not really change the effects on the log, still no radius mentioned.

I do see : "adding payload:" CERT, EAP, SKF

Posted: **Wed Feb 12, 2025 6:48 pm**

So what is in the EKU of the my.dnsname.com certificate - is the tls-server bit set? And does the certificate use an ECP key, as you use one in DH-group in Phase 1 and Phase 2 proposals?

Posted: **Wed Feb 12, 2025 6:49 pm**

17:37:46 ipsec adding payload: EAP
17:37:46 ipsec,debug => (size 0x9)
17:37:46 ipsec <- ike2 reply, exchange: AUTH:1 client.pub.lic.ip[64374] hex:hex
17:37:46 ipsec fragmenting into 2 chunks
17:37:46 ipsec adding payload: SKF
17:37:46 ipsec,debug => (first 0x100 of 0x498)
17:37:46 ipsec,debug lot of hex data
17:37:46 ipsec adding payload: SKF
17:37:46 ipsec,debug => (first 0x100 of 0x348)
17:37:46 ipsec,debug lot of hex data again
17:37:46 ipsec,debug ===== sending 1204 bytes from mikrotik.lo.cal.ip[4500] to client.pub.lic.ip[64374]
17:37:46 ipsec,debug 1 times of 1208 bytes message will be sent to client.pub.lic.ip[64374]
17:37:46 ipsec,debug ===== sending 868 bytes from mikrotik.lo.cal.ip[4500] to client.pub.lic.ip[64374]
17:37:46 ipsec,debug 1 times of 872 bytes message will be sent to client.pub.lic.ip[64374]
17:37:57 ipsec,debug KA: mikrotik.lo.cal.ip[4500]->client.pub.lic.ip[64374]
17:37:57 ipsec,debug 1 times of 1 bytes message will be sent to client.pub.lic.ip[64374]
17:38:14 route,rpki,debug stats roas 0 roa 0 nodes4 0 nodes6 0
17:38:14 route,debug,calc route/calc/publish
17:38:14 route,rpki,debug wipe stats roas 0 roa 0 nodes4 0 nodes6 0
17:38:16 ipsec child negotiation timeout in state 2
17:38:16 ipsec,info killing ike2 SA: ike2-responder mikrotik.lo.cal.ip[4500]->client.pub.lic.ip[64374] spi:hex:hex
17:38:16 ipsec KA remove: mikrotik.lo.cal.ip[4500]->client.pub.lic.ip[64374]
17:38:16 ipsec,debug KA tree dump: mikrotik.lo.cal.ip[4500]->client.pub.lic.ip[64374] (in_use=1)
17:38:16 ipsec,debug KA removing this one...

Posted: **Wed Feb 12, 2025 6:54 pm**

EKU contains TLS server and client.
Added DisableIKENameEkuCheck=1 to the registry.

ECP key(?) i dont really know, dont think so.
I adjusted it / added it because the log metionned a mismatch.

I did try a new client on the windows side, default config.

P.S.
I succeeded in getting it back to using a proposal with dh=modp1024
The log shows a different sequence that ends similar (see above posted log).
The difference is:
After payload: EAP, SKF,SKF the following is repeated several times:
17:57:11 ipsec -> ike2 request, exchange: AUTH:1 client.pub.lic.ip[64378] <hex>

PPS:
I do not have the fake external-IP interface yet!

Posted: **Thu Feb 13, 2025 1:42 pm**

Got the trick with local IP hiding by dst-nat working too. It doesnt help.
Logging better now, also. Created/edited 2 extensive logs, one without dst-nat, and one with dst-nat.
without dst-nat:

 12:17:39 ipsec -> ike2 request, exchange: SA_INIT:0 vpn.client.public.ip[64619] xxxxxxxxxxxxxxxx:0000000000000000
 12:17:39 ipsec ike2 respond
 12:17:39 ipsec payload seen: SA
 12:17:39 ipsec payload seen: KE
 12:17:39 ipsec payload seen: NONCE
 12:17:39 ipsec payload seen: NOTIFY
 12:17:39 ipsec payload seen: NOTIFY
 12:17:39 ipsec payload seen: NOTIFY
 12:17:39 ipsec payload seen: VID
 12:17:39 ipsec payload seen: VID
 12:17:39 ipsec payload seen: VID
 12:17:39 ipsec payload seen: VID
 12:17:39 ipsec processing payload: SA
 12:17:39 ipsec IKE Protocol: IKE
 12:17:39 ipsec  proposal #1
 12:17:39 ipsec   enc: 3des-cbc
 12:17:39 ipsec   prf: hmac-sha1
 12:17:39 ipsec   auth: sha1
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec  proposal #2
 12:17:39 ipsec   enc: aes256-cbc
 12:17:39 ipsec   prf: hmac-sha1
 12:17:39 ipsec   auth: sha1
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec  proposal #3
 12:17:39 ipsec   enc: 3des-cbc
 12:17:39 ipsec   prf: hmac-sha256
 12:17:39 ipsec   auth: sha256
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec  proposal #4
 12:17:39 ipsec   enc: aes256-cbc
 12:17:39 ipsec   prf: hmac-sha256
 12:17:39 ipsec   auth: sha256
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec  proposal #5
 12:17:39 ipsec   enc: 3des-cbc
 12:17:39 ipsec   prf: hmac-sha384
 12:17:39 ipsec   auth: sha384
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec  proposal #6
 12:17:39 ipsec   enc: aes256-cbc
 12:17:39 ipsec   prf: hmac-sha384
 12:17:39 ipsec   auth: sha384
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec matched proposal:
 12:17:39 ipsec  proposal #4
 12:17:39 ipsec   enc: aes256-cbc
 12:17:39 ipsec   prf: hmac-sha256
 12:17:39 ipsec   auth: sha256
 12:17:39 ipsec   dh: modp1024
 12:17:39 ipsec processing payload: KE
 12:17:39 ipsec ike2 respond finish: request, exchange: SA_INIT:0 vpn.client.public.ip[64619] xxxxxxxxxxxxxxxx:0000000000000000
 12:17:39 ipsec processing payload: NONCE
 12:17:39 ipsec adding payload: SA
 12:17:39 ipsec adding payload: KE
 12:17:39 ipsec adding payload: NONCE
 12:17:39 ipsec adding notify: NAT_DETECTION_SOURCE_IP
 12:17:39 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
 12:17:39 ipsec adding notify: IKEV2_FRAGMENTATION_SUPPORTED
 12:17:39 ipsec adding payload: CERTREQ
 12:17:39 ipsec <- ike2 reply, exchange: SA_INIT:0 vpn.client.public.ip[64619] xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy
 12:17:39 ipsec,info new ike2 SA (R): ike2-responder mikro.tik.local.ip[500]-vpn.client.public.ip[64619] spi:yyyyyyyyyyyyyyyy:xxxxxxxxxxxxxxxx
 12:17:39 ipsec processing payloads: VID
 12:17:39 ipsec peer is MS Windows (ISAKMPOAKLEY 9)
 12:17:39 ipsec processing payloads: NOTIFY
 12:17:39 ipsec   notify: IKEV2_FRAGMENTATION_SUPPORTED
 12:17:39 ipsec   notify: NAT_DETECTION_SOURCE_IP
 12:17:39 ipsec   notify: NAT_DETECTION_DESTINATION_IP
 12:17:39 ipsec (NAT-T) REMOTE
 12:17:39 ipsec KA list add: mikro.tik.local.ip[4500]->vpn.client.public.ip[64619]
 12:17:39 ipsec fragmentation negotiated
 12:17:39 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy
 12:17:39 ipsec peer ports changed: 64619 -> 64620
 12:17:39 ipsec KA remove: mikro.tik.local.ip[4500]->vpn.client.public.ip[64619]
 12:17:39 ipsec KA list add: mikro.tik.local.ip[4500]->vpn.client.public.ip[64620]
 12:17:39 ipsec payload seen: SKF
 12:17:39 ipsec processing payload: ENC (not found)
 12:17:39 ipsec processing payload: SKF
 12:17:39 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy
 12:17:39 ipsec payload seen: SKF
 12:17:39 ipsec processing payload: ENC (not found)
 12:17:39 ipsec processing payload: SKF
 12:17:39 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy
 12:17:39 ipsec payload seen: SKF
 12:17:39 ipsec processing payload: ENC (not found)
 12:17:39 ipsec processing payload: SKF
 12:17:39 ipsec payload seen: ID_I
 12:17:39 ipsec payload seen: CERTREQ
 12:17:39 ipsec payload seen: NOTIFY
 12:17:39 ipsec payload seen: CONFIG
 12:17:39 ipsec payload seen: SA
 12:17:39 ipsec payload seen: TS_I
 12:17:39 ipsec payload seen: TS_R
 12:17:39 ipsec processing payloads: NOTIFY
 12:17:39 ipsec   notify: MOBIKE_SUPPORTED
 12:17:39 ipsec ike auth: respond
 12:17:39 ipsec processing payload: ID_I
 12:17:39 ipsec ID_I (ADDR4): vpn.client.local.ip
 12:17:39 ipsec processing payload: ID_R (not found)
 12:17:39 ipsec processing payload: AUTH (not found)
 12:17:39 ipsec processing payloads: NOTIFY
 12:17:39 ipsec   notify: MOBIKE_SUPPORTED
 12:17:39 ipsec ID_R (DER DN): CN=my.domainname.com
 12:17:39 ipsec adding payload: ID_R
 12:17:39 ipsec adding payload: AUTH
 12:17:39 ipsec Certificate:
 12:17:39 ipsec   serialNr:  <MyLetsEncryptCertificateSerialNumber>
 12:17:39 ipsec   issuer:    <C=US, O=Let\'s Encrypt, CN=R11>
 12:17:39 ipsec   subject:   <CN=my.domainname.com>
 12:17:39 ipsec   notBefore: Wed Feb 12 12:06:47 2025
 12:17:39 ipsec   notAfter:  Tue May 13 12:06:46 2025
 12:17:39 ipsec   selfSigned:0
 12:17:39 ipsec   extensions:
 12:17:39 ipsec     key usage: digital-signature, key-encipherment
 12:17:39 ipsec     extended key usage: tls-server, tls-client
 12:17:39 ipsec     basic constraints: isCa: FALSE
 12:17:39 ipsec     subject key id:  <MySubjectKeyId>
 12:17:39 ipsec     authority key id:<MyAuthorityKeyId>
 12:17:39 ipsec     subject alternative name:
 12:17:39 ipsec       DNS: my.domainname.com
 12:17:39 ipsec   signed with: SHA256+RSA
 12:17:39 ipsec [RSA-PUBLIC]
 12:17:39 ipsec modulus: <long hex>
 12:17:39 ipsec publicExponent: 10001
 12:17:39 ipsec adding payload: CERT
 12:17:39 ipsec adding payload: EAP
 12:17:39 ipsec <- ike2 reply, exchange: AUTH:1 vpn.client.public.ip[64620] xxxxxxxxxxxxxxxx:yyyyyyyyyyyyyyyy
 12:17:39 ipsec fragmenting into 2 chunks
 12:17:39 ipsec adding payload: SKF
 12:17:39 ipsec adding payload: SKF
 12:18:09 ipsec child negotiation timeout in state 2
 12:18:09 ipsec,info killing ike2 SA: ike2-responder mikro.tik.local.ip[4500]-vpn.client.public.ip[64620] spi:yyyyyyyyyyyyyyyy:xxxxxxxxxxxxxxxx
 12:18:09 ipsec KA remove: mikro.tik.local.ip[4500]->vpn.client.public.ip[64620]

Posted: **Thu Feb 13, 2025 1:46 pm**

(For some reason the forum-software doesnt deal correctly with the 2nd code-section when in the same post...)
(PS. probable the ' (tick) in Let's, escaped it now with a backslash.)

with dst-nat:

 12:19:01 ipsec -> ike2 request, exchange: SA_INIT:0 vpn.client.public.ip[64619] nnnnnnnnnnnnnnnn:0000000000000000
 12:19:01 ipsec ike2 respond
 12:19:01 ipsec payload seen: SA
 12:19:01 ipsec payload seen: KE
 12:19:01 ipsec payload seen: NONCE
 12:19:01 ipsec payload seen: NOTIFY
 12:19:01 ipsec payload seen: NOTIFY
 12:19:01 ipsec payload seen: NOTIFY
 12:19:01 ipsec payload seen: VID
 12:19:01 ipsec payload seen: VID
 12:19:01 ipsec payload seen: VID
 12:19:01 ipsec payload seen: VID
 12:19:01 ipsec processing payload: SA
 12:19:01 ipsec IKE Protocol: IKE
 12:19:01 ipsec  proposal #1
 12:19:01 ipsec   enc: 3des-cbc
 12:19:01 ipsec   prf: hmac-sha1
 12:19:01 ipsec   auth: sha1
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec  proposal #2
 12:19:01 ipsec   enc: aes256-cbc
 12:19:01 ipsec   prf: hmac-sha1
 12:19:01 ipsec   auth: sha1
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec  proposal #3
 12:19:01 ipsec   enc: 3des-cbc
 12:19:01 ipsec   prf: hmac-sha256
 12:19:01 ipsec   auth: sha256
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec  proposal #4
 12:19:01 ipsec   enc: aes256-cbc
 12:19:01 ipsec   prf: hmac-sha256
 12:19:01 ipsec   auth: sha256
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec  proposal #5
 12:19:01 ipsec   enc: 3des-cbc
 12:19:01 ipsec   prf: hmac-sha384
 12:19:01 ipsec   auth: sha384
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec  proposal #6
 12:19:01 ipsec   enc: aes256-cbc
 12:19:01 ipsec   prf: hmac-sha384
 12:19:01 ipsec   auth: sha384
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec matched proposal:
 12:19:01 ipsec  proposal #4
 12:19:01 ipsec   enc: aes256-cbc
 12:19:01 ipsec   prf: hmac-sha256
 12:19:01 ipsec   auth: sha256
 12:19:01 ipsec   dh: modp1024
 12:19:01 ipsec processing payload: KE
 12:19:01 ipsec ike2 respond finish: request, exchange: SA_INIT:0 vpn.client.public.ip[64619] mmmmmmmmmmmmmmmm:0000000000000000
 12:19:01 ipsec processing payload: NONCE
 12:19:01 ipsec adding payload: SA
 12:19:01 ipsec adding payload: KE
 12:19:01 ipsec adding payload: NONCE
 12:19:01 ipsec adding notify: NAT_DETECTION_SOURCE_IP
 12:19:01 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
 12:19:01 ipsec adding notify: IKEV2_FRAGMENTATION_SUPPORTED
 12:19:01 ipsec adding payload: CERTREQ
 12:19:01 ipsec <- ike2 reply, exchange: SA_INIT:0 vpn.client.public.ip[64619] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:01 ipsec,info new ike2 SA (R): ike2-responder mikro.tik.public.ip[500]-vpn.client.public.ip[64619] spi:nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 12:19:01 ipsec processing payloads: VID
 12:19:01 ipsec peer is MS Windows (ISAKMPOAKLEY 9)
 12:19:01 ipsec processing payloads: NOTIFY
 12:19:01 ipsec   notify: IKEV2_FRAGMENTATION_SUPPORTED
 12:19:01 ipsec   notify: NAT_DETECTION_SOURCE_IP
 12:19:01 ipsec   notify: NAT_DETECTION_DESTINATION_IP
 12:19:01 ipsec (NAT-T) REMOTE
 12:19:01 ipsec KA list add: mikro.tik.public.ip[4500]->vpn.client.public.ip[64619]
 12:19:01 ipsec fragmentation negotiated
 12:19:01 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:01 ipsec peer ports changed: 64619 -> 64620
 12:19:01 ipsec KA remove: mikro.tik.public.ip[4500]->vpn.client.public.ip[64619]
 12:19:01 ipsec KA list add: mikro.tik.public.ip[4500]->vpn.client.public.ip[64620]
 12:19:01 ipsec payload seen: SKF
 12:19:01 ipsec processing payload: ENC (not found)
 12:19:01 ipsec processing payload: SKF
 12:19:01 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:01 ipsec payload seen: SKF
 12:19:01 ipsec processing payload: ENC (not found)
 12:19:01 ipsec processing payload: SKF
 12:19:01 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:01 ipsec payload seen: SKF
 12:19:01 ipsec processing payload: ENC (not found)
 12:19:01 ipsec processing payload: SKF
 12:19:01 ipsec payload seen: ID_I
 12:19:01 ipsec payload seen: CERTREQ
 12:19:01 ipsec payload seen: NOTIFY
 12:19:01 ipsec payload seen: CONFIG
 12:19:01 ipsec payload seen: SA
 12:19:01 ipsec payload seen: TS_I
 12:19:01 ipsec payload seen: TS_R
 12:19:01 ipsec processing payloads: NOTIFY
 12:19:01 ipsec   notify: MOBIKE_SUPPORTED
 12:19:01 ipsec ike auth: respond
 12:19:01 ipsec processing payload: ID_I
 12:19:01 ipsec ID_I (ADDR4): vpn.client.local.ip
 12:19:01 ipsec processing payload: ID_R (not found)
 12:19:01 ipsec processing payload: AUTH (not found)
 12:19:01 ipsec processing payloads: NOTIFY
 12:19:01 ipsec   notify: MOBIKE_SUPPORTED
 12:19:01 ipsec ID_R (DER DN): CN=my.domainname.com
 12:19:01 ipsec adding payload: ID_R
 12:19:01 ipsec adding payload: AUTH
 12:19:01 ipsec Certificate:
 12:19:01 ipsec   serialNr:  <MyLetsEncryptCertificateSerialNumber>
 12:19:01 ipsec   issuer:    <C=US, O=Let\'s Encrypt, CN=R11>
 12:19:01 ipsec   subject:   <CN=my.domainname.com>
 12:19:01 ipsec   notBefore: Wed Feb 12 12:06:47 2025
 12:19:01 ipsec   notAfter:  Tue May 13 12:06:46 2025
 12:19:01 ipsec   selfSigned:0
 12:19:01 ipsec   extensions:
 12:19:01 ipsec     key usage: digital-signature, key-encipherment
 12:19:01 ipsec     extended key usage: tls-server, tls-client
 12:19:01 ipsec     basic constraints: isCa: FALSE
 12:19:01 ipsec     subject key id:  <MySubjectKeyId>
 12:19:01 ipsec     authority key id:<MyAuthorityKeyId>
 12:19:01 ipsec     subject alternative name:
 12:19:01 ipsec       DNS: my.domainname.com
 12:19:01 ipsec   signed with: SHA256+RSA
 12:19:01 ipsec [RSA-PUBLIC]
 12:19:01 ipsec modulus: <long hex>
 12:19:01 ipsec publicExponent: 10001
 12:19:01 ipsec adding payload: CERT
 12:19:01 ipsec adding payload: EAP
 12:19:01 ipsec <- ike2 reply, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:01 ipsec fragmenting into 2 chunks
 12:19:01 ipsec adding payload: SKF
 12:19:01 ipsec adding payload: SKF
 12:19:02 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:02 ipsec retransmitting reply
 12:19:02 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:02 ipsec retransmitting reply
 12:19:02 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:02 ipsec retransmitting reply
 12:19:03 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:03 ipsec retransmitting reply
 12:19:03 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:03 ipsec retransmitting reply
 12:19:03 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64620] mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 12:19:03 ipsec retransmitting reply
 12:19:31 ipsec child negotiation timeout in state 2
 12:19:31 ipsec,info killing ike2 SA: ike2-responder mikro.tik.public.ip[4500]-vpn.client.public.ip[64620] spi:nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 12:19:31 ipsec KA remove: mikro.tik.public.ip[4500]->vpn.client.public.ip[64620]

Posted: **Thu Feb 13, 2025 1:50 pm**

Can't help, but a notice:
It's 2025, IPsec is an old, outdated overcomplicated, error-prone dinosaur.
If possible, use a modern technology like Wireguard.

Posted: **Thu Feb 13, 2025 1:52 pm**

ooooh didnt think of that....
Reeeeaally helpfull.

(Sorry for that. A little frustrated here. I have constraints here, cannot choose justr anything i would like.)

Posted: **Thu Feb 13, 2025 2:09 pm**

@sindy :

The biggest problem still seems to be the certificate.
The windows client still reports 'unacceptable'.
You have any idea what could be wrong / what to try next ?

Posted: **Thu Feb 13, 2025 2:18 pm**

Windows are not famous for useful error messages, they report unnacceptable for almost everything

What I can see in the logs that Windows either do not get the auth response from us or they do not bother to send NOTIFY with rejection payload in response. Can you verify which case it is using Wireshark?

Posted: **Thu Feb 13, 2025 2:21 pm**

Yes, i already had wireshark running along on the client.
Just a moment, i'll have to search a bit.

Posted: **Thu Feb 13, 2025 2:26 pm**

@Guscht: Can't help, but a notice: It's 2025, IPsec is an old, outdated overcomplicated, error-prone dinosaur. If possible, use a modern technology like Wireguard.

Sure, IPsec is a "dinosaur" — just one that happens to be the standard for countless enterprises, governments, and critical infrastructure worldwide. WireGuard is excellent, though, for home users or perhaps out-of-band management. IPsec supports hardware acceleration; WireGuard does not (on any platform or brand due to ChaCha20).

If you don’t have anything useful to add, you could at least try to stay in touch with reality.

Posted: **Thu Feb 13, 2025 2:33 pm**

Not sure here... Can send you more info when u name the packet#

Naamloos.png

Posted: **Thu Feb 13, 2025 2:38 pm**

To me it seems that the initiator (Windows) auth requests (fragment 1 of 3 etc.) do not reach the Mikrotik, as I can see retransmissions in both the Mikrotik log and the Wireshark from Windows. Do you forward also UDP port 4500 from the public IP to Mikrotik's WAN?

Posted: **Thu Feb 13, 2025 2:41 pm**

I see...
That is the case in the second connect, where the local IP is hidden by dst-nat..
I guess something is wrong there.

PS. see the 2 log, and the 2 connects (by time)

Posted: **Thu Feb 13, 2025 2:44 pm**

The dsl modem has forwards for 500 and 4500 to the mikrotik, yes.

NAT setcion firewall mkrotik:|

0 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none
1 chain=dstnat action=dst-nat to-addresses=80.153.xxx.xxx protocol=udp dst-address=10.0.yy.yyy dst-port=500,4500 log=no log-prefix=""

Posted: **Thu Feb 13, 2025 2:46 pm**

I guess something is wrong there.

If you use the trick with public address on the Mikrotik itself, it must be set as a local-address on the peer. The dst-nat rules are OK.

Posted: **Thu Feb 13, 2025 2:51 pm**

The first log, and first connect in wireshark @ 12:17:39 is without dst-nat.
The second log, and second connect in wireshark @12:19:01 is with dst-nat.

In the second case the retransmissions occur.
Maybe the dsl-modem will not forward its own spoofed IP as source, or the reply has no interface to exit the mikrotik ?
Wild guessing there

Posted: **Thu Feb 13, 2025 2:59 pm**

/interface/bridge/print
Flags: X - disabled, R - running
0 R ;;; defconf
name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=D4:01:C3:..:..:9E protocol-mode=none fast-forward=yes igmp-snooping=no auto-mac=no admin-mac=D4:01:C3:..:..:9E ageing-time=5m vlan-filtering=no dhcp-snooping=no
port-cost-mode=short mvrp=no forward-reserved-addresses=no max-learned-entries=auto

1 R name="fakeWANbridge" mtu=auto actual-mtu=1500 l2mtu=65535 arp=disabled arp-timeout=auto mac-address=1E:65:64:..:..:E2 protocol-mode=none fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m vlan-filtering=no dhcp-snooping=no port-cost-mode=long mvrp=no
forward-reserved-addresses=no max-learned-entries=auto

/ip/address> print
Columns: ADDRESS, NETWORK, INTERFACE
# ADDRESS NETWORK INTERFACE
;;; local switch
0 10.0.yy.yyy/24 10.0.yy.0 bridge
;;; FakeWAN
1 80.153.xx.xxx/32 80.153.xx.xxx fakeWANbridge

Posted: **Thu Feb 13, 2025 3:18 pm**

Strange, now i do no longer see any retransmits..

The wireshark capture now shows :
IKE_SA_INIT MID=00 Initiator Request
IKE_SA_INIT MID=00 Responder Response
IKE_AUTH MID=01 Initiator Request (3 fragments)
IKE_AUTH MID=01 Responder Response (2 fragments)
NAT-keepalive (2 times)

The windows client still finishes with "certificate/auth unacceptable" (13801?)

Added some extra logging to the mikrotik log (with dst-nat enabled)

 14:11:26 ipsec -> ike2 request, exchange: SA_INIT:0 vpn.client.public.ip[64691] nnnnnnnnnnnnnnnn:0000000000000000
 14:11:26 ipsec ike2 respond
 14:11:26 ipsec payload seen: SA
 14:11:26 ipsec payload seen: KE
 14:11:26 ipsec payload seen: NONCE
 14:11:26 ipsec payload seen: NOTIFY
 14:11:26 ipsec payload seen: NOTIFY
 14:11:26 ipsec payload seen: NOTIFY
 14:11:26 ipsec payload seen: VID
 14:11:26 ipsec payload seen: VID
 14:11:26 ipsec payload seen: VID
 14:11:26 ipsec payload seen: VID
 14:11:26 ipsec processing payload: SA
 14:11:26 ipsec IKE Protocol: IKE
 14:11:26 ipsec  proposal #1
 14:11:26 ipsec   enc: 3des-cbc
 14:11:26 ipsec   prf: hmac-sha1
 14:11:26 ipsec   auth: sha1
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec  proposal #2
 14:11:26 ipsec   enc: aes256-cbc
 14:11:26 ipsec   prf: hmac-sha1
 14:11:26 ipsec   auth: sha1
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec  proposal #3
 14:11:26 ipsec   enc: 3des-cbc
 14:11:26 ipsec   prf: hmac-sha256
 14:11:26 ipsec   auth: sha256
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec  proposal #4
 14:11:26 ipsec   enc: aes256-cbc
 14:11:26 ipsec   prf: hmac-sha256
 14:11:26 ipsec   auth: sha256
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec  proposal #5
 14:11:26 ipsec   enc: 3des-cbc
 14:11:26 ipsec   prf: hmac-sha384
 14:11:26 ipsec   auth: sha384
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec  proposal #6
 14:11:26 ipsec   enc: aes256-cbc
 14:11:26 ipsec   prf: hmac-sha384
 14:11:26 ipsec   auth: sha384
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec matched proposal:
 14:11:26 ipsec  proposal #4
 14:11:26 ipsec   enc: aes256-cbc
 14:11:26 ipsec   prf: hmac-sha256
 14:11:26 ipsec   auth: sha256
 14:11:26 ipsec   dh: modp1024
 14:11:26 ipsec processing payload: KE
 14:11:26 firewall,info dstnat: in:bridge out:(unknown 0), connection-state:new src-mac f0:87:56:..:..:90, proto UDP, vpn.client.public.ip:64691->mikro.tik.local.ip:500, len 652
 14:11:26 ipsec ike2 respond finish: request, exchange: SA_INIT:0 vpn.client.public.ip[64691] nnnnnnnnnnnnnnnn:0000000000000000
 14:11:26 ipsec processing payload: NONCE
 14:11:26 ipsec adding payload: SA
 14:11:26 ipsec adding payload: KE
 14:11:26 ipsec adding payload: NONCE
 14:11:26 ipsec adding notify: NAT_DETECTION_SOURCE_IP
 14:11:26 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
 14:11:26 ipsec adding notify: IKEV2_FRAGMENTATION_SUPPORTED
 14:11:26 ipsec adding payload: CERTREQ
 14:11:26 ipsec <- ike2 reply, exchange: SA_INIT:0 vpn.client.public.ip[64691] nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 14:11:26 ipsec,info new ike2 SA (R): ike2-responder mikro.tik.public.ip[500]-vpn.client.public.ip[64691] spi:mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 14:11:26 ipsec processing payloads: VID
 14:11:26 ipsec peer is MS Windows (ISAKMPOAKLEY 9)
 14:11:26 ipsec processing payloads: NOTIFY
 14:11:26 ipsec   notify: IKEV2_FRAGMENTATION_SUPPORTED
 14:11:26 ipsec   notify: NAT_DETECTION_SOURCE_IP
 14:11:26 ipsec   notify: NAT_DETECTION_DESTINATION_IP
 14:11:26 ipsec (NAT-T) REMOTE
 14:11:26 ipsec KA list add: mikro.tik.public.ip[4500]->vpn.client.public.ip[64691]
 14:11:26 ipsec fragmentation negotiated
 14:11:26 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64689] nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 14:11:26 ipsec peer ports changed: 64691 -> 64689
 14:11:26 ipsec KA remove: mikro.tik.public.ip[4500]->vpn.client.public.ip[64691]
 14:11:26 ipsec KA list add: mikro.tik.public.ip[4500]->vpn.client.public.ip[64689]
 14:11:26 ipsec payload seen: SKF
 14:11:26 ipsec processing payload: ENC (not found)
 14:11:26 ipsec processing payload: SKF
 14:11:26 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64689] nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 14:11:26 ipsec payload seen: SKF
 14:11:26 ipsec processing payload: ENC (not found)
 14:11:26 ipsec processing payload: SKF
 14:11:26 ipsec -> ike2 request, exchange: AUTH:1 vpn.client.public.ip[64689] nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 14:11:26 ipsec payload seen: SKF
 14:11:26 ipsec processing payload: ENC (not found)
 14:11:26 ipsec processing payload: SKF
 14:11:26 firewall,info output: in:(unknown 0) out:bridge, connection-state:established,dnat proto UDP, mikro.tik.public.ip:500->vpn.client.public.ip:64691, NAT (mikro.tik.public.ip:500->mikro.tik.local.ip:500)->vpn.client.public.ip:64691, len 337
 14:11:26 ipsec payload seen: ID_I
 14:11:26 ipsec payload seen: CERTREQ
 14:11:26 ipsec payload seen: NOTIFY
 14:11:26 ipsec payload seen: CONFIG
 14:11:26 ipsec payload seen: SA
 14:11:26 ipsec payload seen: TS_I
 14:11:26 ipsec payload seen: TS_R
 14:11:26 ipsec processing payloads: NOTIFY
 14:11:26 ipsec   notify: MOBIKE_SUPPORTED
 14:11:26 ipsec ike auth: respond
 14:11:26 ipsec processing payload: ID_I
 14:11:26 ipsec ID_I (ADDR4): 192.168.179.7
 14:11:26 ipsec processing payload: ID_R (not found)
 14:11:26 ipsec processing payload: AUTH (not found)
 14:11:26 ipsec processing payloads: NOTIFY
 14:11:26 ipsec   notify: MOBIKE_SUPPORTED
 14:11:26 ipsec ID_R (DER DN): CN=my.domainname.com
 14:11:26 ipsec adding payload: ID_R
 14:11:26 ipsec adding payload: AUTH
 14:11:26 ipsec Certificate:
 14:11:26 ipsec   serialNr:  
 14:11:26 ipsec   issuer:    <C=US, O=Let\'s Encrypt, CN=R11>
 14:11:26 ipsec   subject:   <CN=my.domainname.com>
 14:11:26 ipsec   notBefore: Wed Feb 12 12:06:47 2025
 14:11:26 ipsec   notAfter:  Tue May 13 12:06:46 2025
 14:11:26 ipsec   selfSigned:0
 14:11:26 ipsec   extensions:
 14:11:26 ipsec     key usage: digital-signature, key-encipherment
 14:11:26 ipsec     extended key usage: tls-server, tls-client
 14:11:26 ipsec     basic constraints: isCa: FALSE
 14:11:26 ipsec     subject key id:  
 14:11:26 ipsec     authority key id:
 14:11:26 ipsec     subject alternative name:
 14:11:26 ipsec       DNS: my.domainname.com
 14:11:26 ipsec   signed with: SHA256+RSA
 14:11:26 ipsec [RSA-PUBLIC]
 14:11:26 ipsec modulus: <long hex>
 14:11:26 ipsec publicExponent: 10001
 14:11:26 ipsec adding payload: CERT
 14:11:26 ipsec adding payload: EAP
 14:11:26 ipsec <- ike2 reply, exchange: AUTH:1 vpn.client.public.ip[64689] nnnnnnnnnnnnnnnn:mmmmmmmmmmmmmmmm
 14:11:26 ipsec fragmenting into 2 chunks
 14:11:26 ipsec adding payload: SKF
 14:11:26 ipsec adding payload: SKF
 14:11:26 firewall,info output: in:(unknown 0) out:bridge, connection-state:established,dnat proto UDP, mikro.tik.public.ip:4500->vpn.client.public.ip:64689, NAT (mikro.tik.public.ip:4500->mikro.tik.local.ip:4500)->vpn.client.public.ip:64689, len 1284
 14:11:26 firewall,info output: in:(unknown 0) out:bridge, connection-state:established,dnat proto UDP, mikro.tik.public.ip:4500->vpn.client.public.ip:64689, NAT (mikro.tik.public.ip:4500->mikro.tik.local.ip:4500)->vpn.client.public.ip:64689, len 868
 14:11:28 firewall,info output: in:(unknown 0) out:bridge, connection-state:established,dnat proto UDP, mikro.tik.public.ip:4500->vpn.client.public.ip:64689, NAT (mikro.tik.public.ip:4500->mikro.tik.local.ip:4500)->vpn.client.public.ip:64689, len 29
 14:11:48 firewall,info output: in:(unknown 0) out:bridge, connection-state:established,dnat proto UDP, mikro.tik.public.ip:4500->vpn.client.public.ip:64689, NAT (mikro.tik.public.ip:4500->mikro.tik.local.ip:4500)->vpn.client.public.ip:64689, len 29
 14:11:56 ipsec child negotiation timeout in state 2
 14:11:56 ipsec,info killing ike2 SA: ike2-responder mikro.tik.public.ip[4500]-vpn.client.public.ip[64689] spi:mmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnn
 14:11:56 ipsec KA remove: mikro.tik.public.ip[4500]->vpn.client.public.ip[64689]

@sindy : note the firewall log-only rule shows the outgoing packets

Still stuck on the windows client that tells me nothing / logs nothing. Any ideas ?

Posted: **Thu Feb 13, 2025 3:28 pm**

Run Wireshark simultaneously with logging on Mikrotik and compare whether the packets shown in firewall log of Mikrotik indeed made it to Windows. It is strange that it behaves different in the individual attempts.

Posted: **Thu Feb 13, 2025 3:33 pm**

Strange indeed. Sorry, cannot reproduce that.

time is sync with above logs
The responses (2) make it to the client. Then the client stops. It says: "IKE-authentification-references are unacceptable" (srry have to translate that from dutch)

Posted: **Thu Feb 13, 2025 3:44 pm**

I see the peer active in webfig, but no installed SA
The ID of the peer is its local IP (192.168...) is that right ?

Posted: **Thu Feb 13, 2025 3:50 pm**

ID of the peer is not really relevant as in the current configuration, it should be ignored when matching the /ip/ipsec/identity row. As the Windows throw the error upon receiving the certificate from the Mikrotik, you are most likely right that they do not like the contents of the certificate. And, quite logically, no Phase 2 SA is created until authentication has passed successfully.

Posted: **Thu Feb 13, 2025 3:57 pm**

But why?

I think the client is configured wrong.
- No certificate installed. Should i ?
- EAP-MSCHAPv2 , ok ?

Posted: **Thu Feb 13, 2025 4:11 pm**

Hmm, user-manager was wrong i think. I changed it now (from-to) but that also didnt help.

/user-manager> print
enabled: no
authentication-port: 1812
accounting-port: 1813
certificate: none
use-profiles: no
require-message-auth: yes-access-request

/user-manager> print
enabled: yes
authentication-port: 1812
accounting-port: 1813
certificate: my.domainname.com
use-profiles: no
require-message-auth: yes-access-request

Posted: **Thu Feb 13, 2025 4:30 pm**

Just a long shot, but have you tried checking with extended logging on Windows?

1. "C:\> netsh trace start VpnClient per=yes maxsize=0 filemode=single"
2. Test the VPN connection
3. "C:\> netsh trace stop"
4. Open the .etl file using Event Viewer (eventvwr.msc). The .etl files are usually saved in %LocalAppData%\Temp\NetTraces\.

Here’s a Reddit thread that might offer some clues: https://www.reddit.com/r/mikrotik/comme ... indows_11/

Posted: **Thu Feb 13, 2025 5:07 pm**

wow... the trace generates information... MB's of it.
It contains so many 'unknown' errors and codes i would know where to look.
The reddit thread is about L2TP and doesnt really fit for IKEv2.

I would like to know why the client doesnt like the certificate.
And, i am puzzeled how the client authhenticates itself to the mikrotik.
I found "eap-methods' but am unable to link that with eap-radius

Posted: **Thu Feb 13, 2025 5:47 pm**

For me, it was the simplest possible setup on Windows - no powershell needed.

The Windows must have the certificate of the signing CA of the Mikrotik's certificate among its trusted root CAs. No own certificate of the Windows client is required if you choose username/password authentication. The certificate cipher suite of the own cerificate of the Mikrotik must match the dh-group used, which by default means "do not use ECP" because Windows use modpXXX by default.

Posted: **Thu Feb 13, 2025 6:04 pm**

Here are some other troubleshooting suggestions. Sorry if I misunderstand or missed anything both of you already tried!

- Check that Windows trusts the Mikrotik CA
Open certmgr.msc. Go to "Trusted Root Certification Authorities". Check that the signing CA of the Mikrotik certificate is there. If missing, import the CA certificate again.

- Narrow down the cert issue
Check Event Viewer: "CAPI2 > Operational" for cert validation errors. Or using PowerShell to verify the client certificate is installed, run "Get-ChildItem -Path Cert:\CurrentUser\My" and "certutil -verify "C:\path\to\certificate.cer" to check trust issues.

- Check client auth
Open Windows VPN Settings (ncpa.cpl: Right-click VPN > Properties).
Verify EAP-MSCHAPv2 or EAP-TLS is correctly selected.
Check Event Viewer: EapHost > Operational for aany authentication failures.
Mikrotik shortcut to check just eap: /log print where message~"eap"

- Verify EAP-RADIUS Configuration
Double-check that Windows EAP settings match RADIUS server config.
Monitor RADIUS logs on Mikrotik "/radius monitor"

Posted: **Thu Feb 13, 2025 6:07 pm**

(after sindy's reply)
Yes, i see.

I'll delete the currect vpn-configs on the client and create a new one.
But, the dh=14/modp1024 works, we have seen that in the mikrotik logs (above) where it is selected correctly.

I am not sure the EAP/radius/mschapv2 works.
I have some doubts there regarding the mikrotik config.

I dont see a lets-encrypt root or CA in the windows client.
That worries me a be bit. Maybe that needs manual fixing.

@sindy: Would you like to nose around on the mikrotik, if that helps ?

Posted: **Thu Feb 13, 2025 6:10 pm**

@Larsa : Great! i'll check all your suggestions and report back.

Posted: **Thu Feb 13, 2025 6:52 pm**

......
In practical terms, one way is to use Let's Encrypt or other public authority to issue the own certificate for the responder, because then you don't need to install anything on the Windows clients - the root CA certificate is distributed using Windows Update in this case.
.....

I guess it took that too litterally.

I installed the LE certificate on the windows VPN-client via import.
I deleted the existing windows-vpn-connections on the client and created a very basic new one.
(create new, vpn, domain-name based address, edit properties: dont remember credentials, type IKEv2, encryption required, EAP-TTLS, dont use windows-credentials, no IPv6, No sharing)

It works now...
I have a working connection.

I will start tweaking it now
I dont like the modp1024.
The routing needs improvement.
Check the need of the dst-nat.
Check radius is correct and safe.
Add the time based authenticator.
Etc.

I'll report back here so the community gains the knowledge too.

THANX A LOT !!!!
Especially Sindy & Larsa for the great help !

Posted: **Thu Feb 13, 2025 7:38 pm**

PS:

- Check that Windows trusts the Mikrotik CA
That was the last remaining problem most likely.

- Narrow down the cert issue
That remains a problem for anyone who would like to....
I still have not found a single log entry on the windows client that tells me the certificate was not trusted.

- Check client auth
EAP-MSCHAPv2 or EAP-TTLS+EAP both seem to work.
Event Viewer: EapHost -> That only just now shows succesfull entries. It did not show anything ever before. ZERO entries until now.
Probably because it didnt get that far.
/log print where message~"eap" -> same there, nothing before, charmingly now.

- Verify EAP-RADIUS Configuration
For some reason the user-manager wasnt enabled and was not linked to the certificate. But that was the last previous problem, one of the many before...
(see #41 -> /user-manager set certificate=my.domainname.com enabled=yes

-Monitor RADIUS logs on Mikrotik "/radius monitor"
Very usefull.

PPS. Will continue tuesday 18-02, i am away until then.

Posted: **Thu Feb 13, 2025 8:52 pm**

I guess it took that too litterally.

I installed the LE certificate on the windows VPN-client via import.

There is no reason to import the LE certificate issued for the FQDN of the Mikrotik server to the Windows. But as you said you wouldn't take the Let's Encrypt path, I probably did not give enough details.

The certificate of Let's Encrypt's root CA is pre-installed on Windows, but Let's Encrypt uses one of its intermediate CAs to sign the end certificate, so the presenter of the end certificate (the Mikrotik) must present also the proper intermediate one in the AUTH message. So the intermediates (currently, "R10" and "R11") must be installed in Mikrotik's certificate store and the certificate list on the identity row needs to be set to the current own certificate and the corresponding intermediate one (the intermediate used to sign the end certificate is chosen randomly at each renewal). This way, the Windows client gets from the server the whole chain of trust except the root CA certificate and can veriify it against the root CA that is pre-installed on the Windows.

Posted: **Tue Feb 18, 2025 6:12 pm**

So,... if i understand correctly... :

Installing the LE certificate on the client did work, but is not the right path, because it gets renewed automatically on the server (mikrotik) and then mismatches.
Correct ?

There is only one certificate (KT, my.domainname.com, issued by R11) on the MikroTik now.
Should I also install the intermediate R11 certificate and link it as second certificate to the IPsec identity?
The domaincertificate alone is enough for the https/ssl signing, though.
I installed the domaincertificate automatically, via the ACME-protocol (enable-ssl-certificate),
port 80 open to a number of LE-servers as per instruction video (where i changed the ddns-assigned name to my own domainname).
It should get renewed automatically from now on.
Correct?

How do i get the intermediate CA (R11) on the mikrotik and how do i make it so that this stays correct when the domaincertificate is renewed?

Posted: **Wed Feb 19, 2025 10:47 pm**

Current working settings, standard windows client (tweaked with PS):
Phase1:
21:37:29 ipsec matched proposal:
21:37:29 ipsec proposal #1
21:37:29 ipsec enc: aes256-cbc
21:37:29 ipsec prf: hmac-sha384
21:37:29 ipsec auth: sha384
21:37:29 ipsec dh: ecp384
Phase2:
21:37:30 ipsec matched proposal:
21:37:30 ipsec proposal #1
21:37:30 ipsec enc: aes256-cbc
21:37:30 ipsec auth: sha256

Best possible with this setup i think, and good enough probably.
Anyone better ideas ? Please share them.

The certificate still is my own domain cert.
The hidden internal-IP-trick with a fake interface seems to work fine.
I had to install the LE domain certificate ánd the R11 intermediate on the MikroTik.
Installed the ISRG Root X1 also.

The user-manager and radius on 127.0.0.1 work fine.
The client seems to authenticate only with user and pass thru EAP, that still worries me.
The client machine seems to need no authentication towards the server at all.
That would mean the user can connect for any machine.
I would like to change that: key, certificate, or something like that, pre-installed on the machine, out of reach of the average user.
Anyone please help ?

Also the authenicator (MFA) still needs to be added.
I'll report back when there is progress with that.

Posted: **Wed Feb 19, 2025 11:36 pm**

How do i get the intermediate CA (R11) on the mikrotik and how do i make it so that this stays correct when the domaincertificate is renewed?

Sorry for late reaction, life is intense these days.

The ACME agent in RouterOS requests a new certificate every 60 days, so in any case you need a script that checks whether the first certificate in the certificate item of the /ip/ipsec/identity row matches the one configured for the www-ssl service (or is available in the certificate list, which is just another perspective as the ACME agent removes the old one) and if it doesn't, update that item (which kills ongoing connections).

As for R10 vs. R11 - one approach is to always present both, i.e. to put both to the list statically and only update the first item of the list (the own certificate), the other one is to overwrite the whole list with a new one consisting of only the new own certificate and the single intermediate CA certificate whose skid matches the akid of the new own one. I use the latter method simply because it is "safer", although so far I have not encountered a client that would refuse to connect due to presence of an irrelevant certificate in the server response, and it makes the script only a tad more complicated.

Interestingly, the www-ssl service doesn't require such manual care - it adds the intermediate certificate to the server hello message automatically (but it still need them to be imported in advance).

Posted: **Thu Feb 20, 2025 12:32 pm**

Interestingly, the www-ssl service doesn't require such manual care - it adds the intermediate certificate to the server hello message automatically (but it still need them to be imported in advance).

Hmm, strange. The ssl certificate did work correctly before I imported the R11 certificate to the mikrotik !
That is why i didnt understand that i had to import it. www-ssl didnt need the R11 on the mikrotik at all.
The VPN does on the other hand need the intermediate certificate on the mikrotik and the linking of it in the identity.

The ACME agent in RouterOS requests a new certificate every 60 days, so in any case you need a script that checks ....

I have no experience with scripts on the mikrotik.
Where can i find such a script, or, could you share it ?
.

Posted: **Tue Feb 25, 2025 6:08 pm**

Got the timebased Authenticator working too. That was very easy now..
Just add an base32 otp-secret to each user in the user manager, and create a new entry in an authenticator using the same base32.
Thats all. Add the code to the password when loging in.

@sindy : Could you help me with the script ?

The ACME agent in RouterOS requests a new certificate every 60 days, so in any case you need a script that checks ....

I have no experience with scripts on the mikrotik.
Where can i find such a script, or, could you share it ?
.

Posted: **Tue Feb 25, 2025 7:08 pm**

Posted: **Tue Feb 25, 2025 11:07 pm**

@Larsa, the scripts and search phrases you've suggested do not address the topic of updating the IPsec identity rows whenever the LE certificate gets renewed; the renewal of the LE certificate happens fully automatically in recent versions of RouterOS so scripts are not necessary for that any more.

@MB123456, this is the script I use, but it needs adjustment to your environment, so after pasting the command below into your command line window, you'll have to edit the script source so that the peer name matches yours (or modify the code before pasting it by replacing ike2-responder by your peer's name)

/system script add name=alignLE source=":local currHTTPS [/ip service get www-ssl certificate]\
    \n:local currImCA [/certificate get [find where skid=[/certificate get \$currHTTPS akid]] name]\
    \n:foreach ipsecID in=[/ip ipsec identity find where peer=ike2-responder] do={\
    \n  :local currIPsec ([/ip ipsec identity get \$ipsecID certificate]->0)\
    \n  :if (\$currHTTPS != \$currIPsec) do={\
    \n    /ip/ipsec/identity set \$ipsecID certificate=\"\$currHTTPS,\$currImCA\"\
    \n  }\
    \n}"

You have to use the scheduler to run the script every minute, as the renewal removes the previous certificate from the system completely:

/system scheduler add disabled=yes interval=1m name=alignLE on-event=alignLE start-date=2025-01-01 start-time=00:00:00

The code above contains disabled=no just for the case, so once you check the script itself does its job, you must enable the scheduler row.

The best way to test is to set some unrelated certificate to the identity row(s) you want the script to change, and then run the script manually. If it changes the certificate item to the proper list, it's OK, otherwise look for what went wrong.

Posted: **Tue Feb 25, 2025 11:41 pm**

Totally missed it was about the IPsec identity. Since we're not using ISRG, I wasn't aware that LE certificate creation and renewal is now fully automated by ROS. Can this also manage IPsec certificates using LE?

P.S.
Fixed my previous reply so it won't confuse future readers.

MikroTik

Got stuck building IKEv2 w/ MFA for remote client

Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client

Re: Got stuck building IKEv2 w/ MFA for remote client