Setting up IKEv2 VPN Server behind NAT

RouterOS General
1

Folks,

My Tik is behind NAT (due to ISP), and it gets an internal IP from them.
I want to setup an IKE2 VPN Server on this Tik to allow my Android phone to be part of the LAN.


Phone (192.168.0.10) ----> ISP1 (192.168.0.1, 4.3.2.1) -----> INTERNET -----> ISP2 (8.7.6.5, 192.168.1.1) -----> TIK (192.168.1.10) (192.168.2.1)

I have followed a tutorial from internet, with some adjustments. I’m currently on version 6.46.6.

These were my steps:

1.) Create the CA certificate which will validate all incoming connections

###Replace common name with Public DNS name of VPN appliance
/certificate add common-name="vpn.yourdomain.com Root CA" name=ca days-valid=3650
/certificate sign ca ca-crl-host=192.168.2.1

I’m unsure here about “ca-crl-host”. Shall it be 192.168.2.1 or 192.168.1.10 (i.e. Tik’s LAN or WAN IP)?

2.) Create and sign VPN Server’s certificate

/certificate add common-name=vpn.yourdomain.com key-usage=tls-server name=vpnserver1 days-valid=3650
/certificate sign vpnserver1 ca=ca

3.) Create and sign a client certificate

/certificate add common-name=android key-usage=tls-client name=android days-valid=3650
/certificate sign android ca=ca

4.) Create a new bridge for VPN connections to make it easier to manage with custom rules

/interface bridge add name=vpn-bridge
/ip address add interface=vpn-bridge address=192.168.200.1/24 comment="VPN Bridge IP"

5.) Create a new pool from which VPN clients can get their IPs

/ip pool add name=vpn-pool ranges=192.168.200.100-192.168.200.200

6.) Create a new IPSec entity (ModeConfig, Proposal, Profile, Peer, Policy, Identity):

#Add mode config to use our pool with VPN Bridge's IP as DNS
/ip ipsec mode-config add 
address-pool=vpn-pool address-prefix-length=32 name=vpn-config system-dns=no static-dns=192.168.200.1

/ip ipsec proposal add 
name=vpn-clients auth-algorithms=sha1,sha256 enc-algorithms=aes-128-cbc,aes-256-cbc pfs-group=modp2048

/ip ipsec profile add 
dh-group=modp1024,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=vpn-profile

/ip  ipsec peer add 
name=vpn-peer address=0.0.0.0/0 exchange-mode=ike2 passive=yes profile=vpn-profile

/ip ipsec policy group add 
name=vpn

/ip ipsec policy add 
template=yes src-address=0.0.0.0/0 dst-address=192.168.200.0/24 proposal=vpn-clients group=vpn

/ip ipsec identity add 
peer=vpn-peer auth-method=digital-signature certificate=vpnserver1 generate-policy=port-strict mode-config=vpn-config policy-template-group=vpn

7.) Export certificates from Tik, and import into Android (successful), I can share these details, but no errors were happened, so let me know if needed.

8.) Try connecting: with vpn.yourdomain.com as address, and with CA and “android” client certificates. Android says “Unsuccessful” after 10-15seconds.


Extra info: I have forwarded UDP ports 500 and 4500 in ISP2 Router (to 192.168.1.10).

I have no clue on why it fails, can you please help me with either just looking into my config (I might misconfigured something), either with some tips on debug, or on what to check, what to see in Tik while android is trying to connect.

Thank you very much.

2

Everything you wrote seems fine to me. What you haven’t written is how exactly did you export the client certificate for the Android and what are the properties of the Mikrotik’s certificate.

If the client certificate is not created the proper way, where the client creates a certificate signing request and the CA signs that request, but it is instead completely created outside the client as you did, the export of the certificate must contain also the private key to it. And in order that it did, you must enter a passphrase when doing the export-certificate. Plus if you choose type=pem, the certificate itself and the private key are in separate files; if you choose type=pkcs12, a single file contains the certificate itself, the private key to it, and all the intermediate certificates up to the root CA’s one included.

So the Android may find out it doesn’t have a private key when it attempts to use the certificate. Or it may check the key-usage and not be happy with it (Mikrotik as an IPsec responder only looks for the tls-client bit but the Android may require something else). Or the Android may check Subject-Alt-Name rather than Common name in the responder’s certificate (Strongswan does this). Or there may be some other issue in the communication between the two, which you might see in the log if you set /system logging add topics=ipsec,!packet, run /log print follow-only file=ipsec-startup where topics~“ipsec”, then make one connection attempt, then break the /log print …, download the file ipsec-startup.txt, and start reading it.

3

Hi danergo,

Try setting My ID type as address in your Identity config and put as value in My ID your public IP assigned to tik (i.e 8.7.6.5).

/ip ipsec identity add 
peer=vpn-peer auth-method=digital-signature certificate=vpnserver1 generate-policy=port-strict mode-config=vpn-config policy-template-group=vpn my-id=address:8.7.6.5

Regards,

4

mbaute:

“Public IP assigned to Tik”: 8.7.6.5 is assigned to ISP’s router, not to Tik.

Tik is behind this ISP’s router, and it gots an internal IP assigned by ISP’s router.

Is your suggestion considered this fact?

Thank you!

5

Sindy:

I have exported the certificates (both ca and both the client) from winbox, in PKCS format, and providing a passphrase.
Then I’ve sent over those two files onto my android phone, and then I have opened them, my phone asked me the passphrase, then certificate type (“VPN and app user certificate” or “Wifi certificate”), I have chosen the first one, then asked a name, entered “ca”, and “client”, then said import was successful.

After that, I have setup a new connection on Android, with these settings:

Then when tried connecting, android says “Unsuccessful”.

I have done the log you suggested (thank you!):

I have replaced the actual values to the IP addresses I used here on top for demo purposes:

16:19:36 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[4500] 
16:19:36 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[4500] 
16:19:36 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[1025] 
16:19:36 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[1025] 
16:19:56 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[4500] 
16:19:56 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[4500] 
16:19:56 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[1025] 
16:19:56 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[1025] 
16:20:06 ipsec sending dpd packet 
16:20:06 ipsec <- ike2 request, exchange: INFORMATIONAL:574 4.3.2.1[4500] SOMEMAGICSTUFF 
16:20:06 ipsec,debug ===== sending 112 bytes from 192.168.1.10[4500] to 4.3.2.1[4500] 
16:20:06 ipsec,debug 1 times of 116 bytes message will be sent to 4.3.2.1[4500] 
16:20:06 ipsec,debug ===== received 96 bytes from 4.3.2.1[4500] to 192.168.1.10[4500] 
16:20:06 ipsec -> ike2 reply, exchange: INFORMATIONAL:574 4.3.2.1[4500] SOMEMAGICSTUFF 
16:20:06 ipsec payload seen: ENC (68 bytes) 
16:20:06 ipsec processing payload: ENC 
16:20:06 ipsec,debug => iv (size 0x10) 
16:20:06 ipsec,debug SOME OTHER MAGIC STUFF 
16:20:06 ipsec,debug => plain payload (trimmed) (size 0x0) 
16:20:06 ipsec,debug decrypted 
16:20:06 ipsec respond: info 
16:20:06 ipsec,debug reply ignored 
16:20:16 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[4500] 
16:20:16 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[4500] 
16:20:16 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[1025] 
16:20:16 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[1025] 
16:20:36 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[4500] 
16:20:36 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[4500] 
16:20:36 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[1025] 
16:20:36 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[1025]
6

You should not have exported the CA certificate using the passphrase, as the private key of the CA should never leave the CA. But this is “only” a security issue (anyone having the CA certificate together with its private key can sign additional certificates that will be trusted by whoever trusts that CA), it does not explain why the connection attempt fails.

The log shows two ongoing IKE sessions, one from remote port 4500 and another one from remote port 1025. Do you have any other client than the Android successfully connected from behind ISP1?

In any case, the log is far too short and nothing resembling the initial establishment packet of the IKEv2 connection is visible there. So either nothing has arrived from the Android, or you haven’t started the log sufficiently earlier than you’ve taken the connection attempt. As the log spans a minute, I rather suspect nothing has arrived from the Android.

So I’d say wait for 15 minutes since the last attempt taken from the Android, then try to log the startup again.

7

http://forum.mikrotik.com/t/ipsec-ike2-with-certificates-vpn-server-guide-for-remote-access/149434/1

You’re welcome :slight_smile:

8

@erkexzcx, if I understand it correctly (no own experience so far), latest Androids support IKEv2 natively, i.e. you don’t need to install Strongswan. The screenshots from the OP suggest that that’s what he’s dealing with here - the graphics does not resemble the one of the Strongswan app.

9

Yes no problem with that, take it as a form of “extra identification” for IPsec, as -because you’re natted-, SAs replying from tik are being sent with your private IP 192.168.1.10. With that ID you’re telling: although my SA tells 192.168.1.10, reply to 8.7.6.5. At least this works on tiks in Google Cloud, where it is always a 1:1 NAT scenario.

Regards,

10

I know, yes, I wanted to avoid any possible blocking to first “just” make it work, then finetune and make it secure (generating new certificates, and changing addresses, etc).


Sindy, I also have a persistent session from another Tik, which we did together long time ago: Split traffic then merge
This is surely working on UDP4500. I have no idea about UDP1025, this is not forwarded on ISP’s router to Tik.
In my earlier log Android and the persistent session were behind the same ISP (which wouldn’t make too much sense and completely out of my scope) - sorry for this.

I have recreated the logs when Android is using LTE, and now it’s much larger, it does a lot of things. After ~160lines, it ends with this error:

07:36:53 ipsec payload seen: NOTIFY (8 bytes) 
07:36:53 ipsec create child: initiator finish 
07:36:53 ipsec processing payloads: NOTIFY 
07:36:53 ipsec   notify: TS_UNACCEPTABLE 
07:36:53 ipsec got error: TS_UNACCEPTABLE

So it seems Traffic Selector has some issues with me, however, it seems IKE2 request and reply is going back and forth between “4.3.2.1” and “192.168.1.10” (indicated with my original network demo IPs).


Thanks. Android version 11 and above supports IKEv2 natively, no need to install Strongswan or any other 3rd party utility.

11

The notification about your update to that thread from this July never made it to my mailbox. I assume you’ve resolved it?


it’s a source port from the perspective of the responder, so it need not be port-forwarded neither at the responder side nor at the initiator one. It’s just that the src-nat in netfilter (used by RouterOS and many other Linux devices) prefers to use the original source port unless that would cause packets belonging to two distinct src-nated connections to be undistinguishable from each other at the WAN side because they’d use the very same remote address:remote port and local address:local port. So the first IPsec connection from 4.3.2.1 to 8.7.6.5:4500 is src-nated to 4.3.2.1:4500, whereas the second one to 4.3.2.1:1024, the third one to 4.3.2.1:1025 etc. The first IPsec connection to somewhere else than 8.7.6.5:4500 can be src-nated to 4.3.2.1:4500 again as the remote address:port is sufficient to distinguish it from the connection 4.3.2.1:4500 → 8.7.6.5:4500.

So now as I’ve seen the actual reason why the Android connection fails to establish, I can reasonably assume that the connection from :1025 was the Android one. I’m not sure whether TS_UNACCEPTABLE breaks the whole session or only the Phase 2 whereas Phase 1 remains up. So it is well possible that the Mikrotik kept sending keepalives within the Phase 1 SA although Phase 2 SA failed to establish, whereas Android has reported an error due to the Phase 2 failure.


Exactly, the authentification has succeeded, otherwise the process would not get as far as to Phase 2 initiation. However, I’d have to see the complete log to say whether the TS suggested by the responder was eventually wrong in some way (not that there was too much to go wrong in a TS itself).

12

No problem at all, it was some ISP error, it actually has resolved itself after some days (I was far away, couldn’t reboot anything)


Here is the complete log:

07:36:41 ipsec ph2 possible after ph1 creation 
07:36:41 ipsec init child for policy: 0.0.0.0/0 <=> 192.168.200.0/24 
07:36:41 ipsec init child continue 
07:36:41 ipsec offering proto: 3 
07:36:41 ipsec  proposal #1 
07:36:41 ipsec   enc: aes256-cbc 
07:36:41 ipsec   enc: aes128-cbc 
07:36:41 ipsec   auth: sha256 
07:36:41 ipsec   auth: sha1 
07:36:41 ipsec   dh: modp2048 
07:36:42 ipsec adding payload: NONCE 
07:36:42 ipsec,debug => (size 0x1c) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec adding payload: KE 
07:36:42 ipsec,debug => (first 0x100 of 0x108) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec adding payload: SA 
07:36:42 ipsec,debug => (size 0x48) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec initiator selector: 0.0.0.0/0 
07:36:42 ipsec adding payload: TS_I 
07:36:42 ipsec,debug => (size 0x18) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec responder selector: 192.168.200.0/24 
07:36:42 ipsec adding payload: TS_R 
07:36:42 ipsec,debug => (size 0x18) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec <- ike2 request, exchange: CREATE_CHILD_SA:4474 4.3.2.1[1025] SOMEMAGICS
07:36:42 ipsec,debug ===== sending 544 bytes from 192.168.1.10[4500] to 4.3.2.1[1025] 
07:36:42 ipsec,debug 1 times of 548 bytes message will be sent to 4.3.2.1[1025] 
07:36:42 ipsec,debug ===== received 240 bytes from 4.3.2.1[1025] to 192.168.1.10[4500] 
07:36:42 ipsec -> ike2 reply, exchange: CREATE_CHILD_SA:4474 4.3.2.1[1025] SOMEMAGICS
07:36:42 ipsec payload seen: ENC (212 bytes) 
07:36:42 ipsec processing payload: ENC 
07:36:42 ipsec,debug => iv (size 0x10) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug => plain payload (trimmed) (size 0x8) 
07:36:42 ipsec,debug SOMEMAGICS
07:36:42 ipsec,debug decrypted 
07:36:42 ipsec payload seen: NOTIFY (8 bytes) 
07:36:42 ipsec create child: initiator finish 
07:36:42 ipsec processing payloads: NOTIFY 
07:36:42 ipsec   notify: TS_UNACCEPTABLE 
07:36:42 ipsec got error: TS_UNACCEPTABLE 
07:36:47 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[4500] 
07:36:47 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[4500] 
07:36:47 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[1025] 
07:36:47 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[1025]

I couldn’t figure out what goes really wrong, thank you so much for your help!

13

What goes wrong is clear - this: responder selector: 192.168.200.0**/24**. The phone should get a single address from the pool via mode-config (or rather its IKEv2 equivalent to be precise).
Why it goes wrong is much harder to answer, as your mode-config clearly states address-prefix-length=32. If I remember properly, it should ask for the SA on its own, so possibly this is the difference to other devices/IPsec implementations, and there’s a bug in Mikrotik that never surfaced because the initiator normally proposes an x.x.x.x/32 → 0.0.0.0/0 traffic selector? If it was that, I wonder where RouterOS gets the /24 from.

So maybe try to set the address associated to the bridge from /24 to /32 and try again, but it’s a blind shot and I can see no reasonable logic behind that.

14

@Sindy,

Maybe from this config:

/ip ipsec policy add 
template=yes src-address=0.0.0.0/0 dst-address=192.168.200.0/[b]24[/b] proposal=vpn-clients group=vpn

Anyway, I have recreated the Policy from scratch, and rebooted the router also.

Now, it’s much worse than before: it seems no packet arrives from Android to Tik at all. However, after reboot, I’ve realised that my 2 active peers happened to be one initiator and one responder.

And somewhere else I remember you wrote something about this limitation, that in case of initiator I’ll have some troubles.

So now to see the clear picture, I have two policies:

/ip ipsec policy
add comment=Tunnel group=default-Tunnel proposal=default-Tunnel template=yes
add comment=VPN dst-address=192.168.200.0/24 group=vpn proposal=vpn-clients src-address=0.0.0.0/0 template=yes

“Tunnel” policy accepted 2 dynamic policy, one of them happened to be initiator side, another one is responder side.

I have tried setting a /32 address to the VPN bridge, doesn’t make any difference.

15

Well… the policy with a /24 at dst-address is a template, but I admit I never dug deep into what happens if the responder has to suggest a TS first because the initiator doesn’t. So you may want to reduce the pool to a single address and set the same address as a /32 in the template, to a) verify the assumption and b) maybe solve the issue for the single phone.

One of the improvements of IKEv2 with regard to IKE(v1) is that it allows to reduce the proposed TS, so if this is the issue, it’s the Android client that should respond with an update from the /24 to /32 rather than rejecting the TS completely. Does the log before Phase 2 show anything regarding the address assignment? Maybe this is what actually fails and the Android phone doesn’t ask for an IP, or asks in a way that RouterOS doesn’t understand? And as it gets no address, it doesn’t ask for a SA, so RouterOS suggests the template, etc.

Of course, why you can see no incoming connection attempts after the reboot is a different question.

As for the initiator and responder - if both your static peers are set to passive=no, then indeed you have two IKE connections, at least for a while. But these should normally not use different ports as both share the same UDP stream.

16

I’m going into a much more easier direction now:

I’ve disabled the persistent tunnel, so now there are no active peers. This way I’ll have the chance to test the VPN server from Windows, and this would be extremely helpful, as my Win is now behind another Tik, so logging will be perfect.

I’ll get back to here once I have more details on this, and after my Win will work, I will move onto Android (because that is the original goal).

Thank you.

17

Guys, I’ve started from scratch and found one basic root-cause: UDP500 was not accepted on the input chain, and therefore it never reached the IKE2 routines.
After adding that, a much nicer and more verbose log was created which however needs some explanation for me, if you could do that:

15:00:23 ipsec,debug ===== received 658 bytes from 4.3.2.1[42618] to 192.168.1.10[500] 
15:00:23 ipsec -> ike2 request, exchange: SA_INIT:0 4.3.2.1[42618] MAGIC 
15:00:23 ipsec ike2 respond 
15:00:23 ipsec payload seen: SA (244 bytes) 
15:00:23 ipsec payload seen: KE (264 bytes) 
15:00:23 ipsec payload seen: NONCE (36 bytes) 
15:00:23 ipsec payload seen: NOTIFY (28 bytes) 
15:00:23 ipsec payload seen: NOTIFY (28 bytes) 
15:00:23 ipsec payload seen: NOTIFY (8 bytes) 
15:00:23 ipsec payload seen: NOTIFY (14 bytes) 
15:00:23 ipsec payload seen: NOTIFY (8 bytes) 
15:00:23 ipsec processing payload: NONCE 
15:00:23 ipsec processing payload: SA 
15:00:23 ipsec,debug unknown auth: #13 
15:00:23 ipsec,debug unknown prf: #6 
15:00:23 ipsec,debug unknown DH group: #24 
15:00:23 ipsec,debug unknown prf: #6 
15:00:23 ipsec,debug unknown DH group: #24 
15:00:23 ipsec IKE Protocol: IKE 
15:00:23 ipsec  proposal #1 
15:00:23 ipsec   enc: aes256-cbc 
15:00:23 ipsec   enc: aes128-cbc 
15:00:23 ipsec   prf: hmac-sha512 
15:00:23 ipsec   prf: unknown 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   prf: hmac-sha1 
15:00:23 ipsec   auth: sha512 
15:00:23 ipsec   auth: unknown 
15:00:23 ipsec   auth: sha256 
15:00:23 ipsec   auth: sha1 
15:00:23 ipsec   dh: unknown 
15:00:23 ipsec   dh: ecp384 
15:00:23 ipsec   dh: ecp256 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec   dh: modp1536 
15:00:23 ipsec  proposal #2 
15:00:23 ipsec   enc: aes256-gcm 
15:00:23 ipsec   enc: aes128-gcm 
15:00:23 ipsec   prf: hmac-sha512 
15:00:23 ipsec   prf: unknown 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   prf: hmac-sha1 
15:00:23 ipsec   dh: unknown 
15:00:23 ipsec   dh: ecp384 
15:00:23 ipsec   dh: ecp256 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec   dh: modp1536 
15:00:23 ipsec matched proposal: 
15:00:23 ipsec  proposal #1 
15:00:23 ipsec   enc: aes256-cbc 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   auth: sha256 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec processing payload: KE 
15:00:23 ipsec unknown DH group: #24 
[b]15:00:23 ipsec DH group number mismatch: 14 != 24[/b]
15:00:23 ipsec adding notify: INVALID_KE_PAYLOAD 
15:00:23 ipsec,debug => (size 0xa) 
15:00:23 ipsec,debug 0000000a 00000011 000e 
15:00:23 ipsec,debug ===== sending 38 bytes from 192.168.1.10[500] to 4.3.2.1[42618] 
15:00:23 ipsec,debug 1 times of 38 bytes message will be sent to 4.3.2.1[42618] 
15:00:23 ipsec,debug ===== received 658 bytes from 4.3.2.1[42618] to 192.168.1.10[500] 
15:00:23 ipsec -> ike2 request, exchange: SA_INIT:0 4.3.2.1[42618] MAGIC
15:00:23 ipsec ike2 respond 
15:00:23 ipsec payload seen: SA (244 bytes) 
15:00:23 ipsec payload seen: KE (264 bytes) 
15:00:23 ipsec payload seen: NONCE (36 bytes) 
15:00:23 ipsec payload seen: NOTIFY (28 bytes) 
15:00:23 ipsec payload seen: NOTIFY (28 bytes) 
15:00:23 ipsec payload seen: NOTIFY (8 bytes) 
15:00:23 ipsec payload seen: NOTIFY (14 bytes) 
15:00:23 ipsec payload seen: NOTIFY (8 bytes) 
15:00:23 ipsec processing payload: NONCE 
15:00:23 ipsec processing payload: SA 
15:00:23 ipsec,debug unknown auth: #13 
15:00:23 ipsec,debug unknown prf: #6 
15:00:23 ipsec,debug unknown DH group: #24 
15:00:23 ipsec,debug unknown prf: #6 
15:00:23 ipsec,debug unknown DH group: #24 
15:00:23 ipsec IKE Protocol: IKE 
15:00:23 ipsec  proposal #1 
15:00:23 ipsec   enc: aes256-cbc 
15:00:23 ipsec   enc: aes128-cbc 
15:00:23 ipsec   prf: hmac-sha512 
15:00:23 ipsec   prf: unknown 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   prf: hmac-sha1 
15:00:23 ipsec   auth: sha512 
15:00:23 ipsec   auth: unknown 
15:00:23 ipsec   auth: sha256 
15:00:23 ipsec   auth: sha1 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec   dh: unknown 
15:00:23 ipsec   dh: ecp384 
15:00:23 ipsec   dh: ecp256 
15:00:23 ipsec   dh: modp1536 
15:00:23 ipsec  proposal #2 
15:00:23 ipsec   enc: aes256-gcm 
15:00:23 ipsec   enc: aes128-gcm 
15:00:23 ipsec   prf: hmac-sha512 
15:00:23 ipsec   prf: unknown 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   prf: hmac-sha1 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec   dh: unknown 
15:00:23 ipsec   dh: ecp384 
15:00:23 ipsec   dh: ecp256 
15:00:23 ipsec   dh: modp1536 
15:00:23 ipsec matched proposal: 
15:00:23 ipsec  proposal #1 
15:00:23 ipsec   enc: aes256-cbc 
15:00:23 ipsec   prf: hmac-sha256 
15:00:23 ipsec   auth: sha256 
15:00:23 ipsec   dh: modp2048 
15:00:23 ipsec processing payload: KE 
15:00:24 ipsec,debug => shared secret (size 0x100) 
...
15:00:24 ipsec adding payload: SA 
15:00:24 ipsec,debug => (size 0x30) 
...
15:00:24 ipsec adding payload: KE 
15:00:24 ipsec,debug => (first 0x100 of 0x108) 
...
15:00:24 ipsec adding payload: NONCE 
15:00:24 ipsec,debug => (size 0x1c) 
...
15:00:24 ipsec adding notify: NAT_DETECTION_SOURCE_IP 
15:00:24 ipsec,debug => (size 0x1c) 
...
15:00:24 ipsec adding notify: NAT_DETECTION_DESTINATION_IP 
15:00:24 ipsec,debug => (size 0x1c) 
...
15:00:24 ipsec adding payload: CERTREQ 
15:00:24 ipsec,debug => (size 0x5) 
...
15:00:24 ipsec <- ike2 reply, exchange: SA_INIT:0 4.3.2.1[42618] MAGIC 
15:00:24 ipsec,debug ===== sending 429 bytes from 192.168.1.10[500] to 4.3.2.1[42618] 
15:00:24 ipsec,debug 1 times of 429 bytes message will be sent to 4.3.2.1[42618] 
15:00:24 ipsec,debug => skeyseed (size 0x20) 
...
15:00:24 ipsec,debug => keymat (size 0x20) 
...
15:00:24 ipsec,debug => SK_ai (size 0x20) 
...
15:00:24 ipsec,debug => SK_ar (size 0x20) 
...
15:00:24 ipsec,debug => SK_ei (size 0x20) 
...
15:00:24 ipsec,debug => SK_er (size 0x20) 
...
15:00:24 ipsec,debug => SK_pi (size 0x20) 
...
15:00:24 ipsec,debug => SK_pr (size 0x20) 
...
15:00:24 ipsec,info new ike2 SA (R): 192.168.1.10[500]-4.3.2.1[42618] spi:MAGIC
15:00:24 ipsec processing payloads: VID (none found) 
15:00:24 ipsec processing payloads: NOTIFY 
15:00:24 ipsec   notify: NAT_DETECTION_SOURCE_IP 
15:00:24 ipsec   notify: NAT_DETECTION_DESTINATION_IP 
15:00:24 ipsec   notify: IKEV2_FRAGMENTATION_SUPPORTED 
15:00:24 ipsec   notify: SIGNATURE_HASH_ALGORITHMS 
15:00:24 ipsec,debug 000200030004 
15:00:24 ipsec   notify: REDIRECT_SUPPORTED 
15:00:24 ipsec (NAT-T) REMOTE LOCAL 
15:00:24 ipsec KA list add: 192.168.1.10[4500]->4.3.2.1[42618] 
15:00:24 ipsec,debug ===== received 658 bytes from 4.3.2.1[42618] to 192.168.1.10[500] 
15:00:24 ipsec -> ike2 request, exchange: SA_INIT:0 4.3.2.1[42618] MAGIC
15:00:24 ipsec ike2 respond 
15:00:24 ipsec payload seen: SA (244 bytes) 
15:00:24 ipsec payload seen: KE (264 bytes) 
15:00:24 ipsec payload seen: NONCE (36 bytes) 
15:00:24 ipsec payload seen: NOTIFY (28 bytes) 
15:00:24 ipsec payload seen: NOTIFY (28 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec payload seen: NOTIFY (14 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec processing payload: NONCE 
15:00:24 ipsec sa init retransmitted  
15:00:24 ipsec,debug ===== sending 429 bytes from 192.168.1.10[500] to 4.3.2.1[42618] 
15:00:24 ipsec,debug 1 times of 429 bytes message will be sent to 4.3.2.1[42618] 
15:00:24 ipsec,debug ===== received 658 bytes from 4.3.2.1[42618] to 192.168.1.10[500] 
15:00:24 ipsec -> ike2 request, exchange: SA_INIT:0 4.3.2.1[42618] MAGIC
15:00:24 ipsec ike2 respond 
15:00:24 ipsec payload seen: SA (244 bytes) 
15:00:24 ipsec payload seen: KE (264 bytes) 
15:00:24 ipsec payload seen: NONCE (36 bytes) 
15:00:24 ipsec payload seen: NOTIFY (28 bytes) 
15:00:24 ipsec payload seen: NOTIFY (28 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec payload seen: NOTIFY (14 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec processing payload: NONCE 
15:00:24 ipsec sa init retransmitted  
15:00:24 ipsec,debug ===== sending 429 bytes from 192.168.1.10[500] to 4.3.2.1[42618] 
15:00:24 ipsec,debug 1 times of 429 bytes message will be sent to 4.3.2.1[42618] 
15:00:24 ipsec,debug KA: 192.168.1.10[4500]->4.3.2.1[42618] 
15:00:24 ipsec,debug 1 times of 1 bytes message will be sent to 4.3.2.1[42618] 
15:00:24 ipsec,debug ===== received 1472 bytes from 4.3.2.1[42278] to 192.168.1.10[4500] 
15:00:24 ipsec -> ike2 request, exchange: AUTH:1 4.3.2.1[42278] MAGIC 
15:00:24 ipsec peer ports changed: 42618 -> 42278 
15:00:24 ipsec KA remove: 192.168.1.10[4500]->4.3.2.1[42618] 
15:00:24 ipsec,debug KA tree dump: 192.168.1.10[4500]->4.3.2.1[42618] (in_use=1) 
15:00:24 ipsec,debug KA tree dump: 192.168.1.10[4500]->4.3.2.1[42618] (in_use=1) 
15:00:24 ipsec,debug KA tree dump: 192.168.1.10[4500]->4.3.2.1[42618] (in_use=1) 
15:00:24 ipsec,debug KA removing this one... 
15:00:24 ipsec KA list add: 192.168.1.10[4500]->4.3.2.1[42278] 
15:00:24 ipsec payload seen: ENC (1444 bytes) 
15:00:24 ipsec processing payload: ENC 
15:00:24 ipsec,debug => iv (size 0x10) 
15:00:24 ipsec,debug ff60e326 e1177c6f 31247509 d1d80824 
15:00:24 ipsec,debug => plain payload (trimmed) (first 0x100 of 0x57f) 
...
15:00:24 ipsec,debug decrypted 
15:00:24 ipsec payload seen: ID_I (25 bytes) 
15:00:24 ipsec payload seen: CERT (845 bytes) 
15:00:24 ipsec payload seen: CERTREQ (25 bytes) 
15:00:24 ipsec payload seen: AUTH (264 bytes) 
15:00:24 ipsec payload seen: CONFIG (16 bytes) 
15:00:24 ipsec payload seen: SA (124 bytes) 
15:00:24 ipsec payload seen: TS_I (24 bytes) 
15:00:24 ipsec payload seen: TS_R (24 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec payload seen: NOTIFY (12 bytes) 
15:00:24 ipsec payload seen: NOTIFY (24 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec payload seen: NOTIFY (8 bytes) 
15:00:24 ipsec processing payloads: NOTIFY 
15:00:24 ipsec   notify: MOBIKE_SUPPORTED 
15:00:24 ipsec   notify: ADDITIONAL_IP4_ADDRESS 
15:00:24 ipsec,debug 64438afe 
15:00:24 ipsec   notify: ADDITIONAL_IP6_ADDRESS 
15:00:24 ipsec,debug 200108f81d3e78ff6c446c1acf2028e5 
15:00:24 ipsec   notify: EAP_ONLY_AUTHENTICATION 
15:00:24 ipsec   notify: IKEV2_MESSAGE_ID_SYNC_SUPPORTED 
15:00:24 ipsec ike auth: respond 
15:00:24 ipsec processing payload: ID_I 
[b]15:00:24 ipsec ID_I (DER DN): myphone[/b]
15:00:24 ipsec processing payload: ID_R (not found) 
15:00:24 ipsec processing payload: AUTH 
15:00:24 ipsec processing payload: CERT 
[b]15:00:24 ipsec got CERT: myphone[/b] 
15:00:24 ipsec,debug => (size 0x348) 
...
...
...
[b]15:00:24 ipsec,error identity not found for peer: DER DN: myphone[/b] 
15:00:24 ipsec reply notify: AUTHENTICATION_FAILED 
15:00:24 ipsec adding notify: AUTHENTICATION_FAILED

First:

15:00:23 ipsec DH group number mismatch: 14 != 24

how can I make DH to not mismatch? (Or is this something I can leave alone?)

Second:

15:00:24 ipsec ID_I (DER DN): myphone
15:00:24 ipsec got CERT: myphone
15:00:24 ipsec,error identity not found for peer: DER DN: myphone

“myphone” is the name of the certificate on my Android. Android asked me a custom name during the import procedure and I gave this name. It sounds pretty obvious that Tik doesn’t know this text, as I have never wrote this into Tik. What is the resolution?

Thank you

18

This indeed worked :astonished:

Now Android is joined to this lovely Tik.

Other question with the DH mismatch would be still interesting though.

Thank you!

19

Folks,

I don’t understand one another thing:

In active peers, I can see my VPN client perfectly. Its “Local Address” is “192.168.1.10”, which is the IP of the Tik from outside (assigned by ISP). Why?

I mean where did we defined this, or how IPsec knows this?

Everything works perfectly, just I don’t understand this, and I like learning new things. :slight_smile:

20

According to the log, the Android proposes multiple DH groups in each Phase 1 proposal, one of which is not recognized by the RouterOS IPsec stack. So RouterOS accepts the proposal, but complains one more time about that. You can safely ignore this complaint.


It’s the local address of the Tik where you run the /ip ipsec active-peers command to/from which the connection with that peer has been established. There’s no magic in it, this information is sourced locally, not received from the peer.

However, the peers do inform each other about the actual IP addresses and ports they use for the connection, in order to find out whether there is a NAT somewhere between them and adjust the transport accordingly. Each peer tells the other one what is its own address and port used for the connection, and from what address and port it has received the other peer’s previous packet; this way, both peers have enough information to compare.