My IKEV2 vpn stopped working

cristian1986 · Thu Aug 01, 2024 4:17 am

Hello everyone, I have to say that I have been very happy with my mikrotik ikev2 vpn server with android clients for many months, configured with this tutorial https://www.youtube.com/watch?v=JYLbNWOCc2c&t=208s. But about 4 days ago it stopped working out of nowhere, the vpn connects to the mikrotik, but the client connected to this vpn now does not browse or reach the lan ip, I have tried with several mikrotik that have this configuration with different internet providers and the same thing happens, the android client has not been updated, I attach the configuration script if someone can give me a start on where to start to fix it please, I loved this configuration because of how simple it was.

/ip ipsec mode-config
add address-pool=POOL_VPN_IPSEC address-prefix-length=32 name=VPN_IPSEC_IKEV2 \
system-dns=no
/ip ipsec policy group
add name=VPN_IPSEC_IKEV2
/ip ipsec profile
add enc-algorithm=aes-256 hash-algorithm=sha256 name=VPN_IPSEC_IKEV2
/ip ipsec peer
add exchange-mode=ike2 name=VPN_IPSEC_IKEV2 passive=yes profile=\
VPN_IPSEC_IKEV2
/ip ipsec proposal
set [ find default=yes ] disabled=yes enc-algorithms=3des
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc name=\
VPN_IPSEC_IKEV2 pfs-group=none
/ip ipsec identity
add generate-policy=port-strict mode-config=VPN_IPSEC_IKEV2 peer=\
VPN_IPSEC_IKEV2 policy-template-group=VPN_IPSEC_IKEV2 secret=tgrtstg%&%rfwfe@@aF
/ip ipsec policy
set 0 disabled=yes
add group=VPN_IPSEC_IKEV2 proposal=VPN_IPSEC_IKEV2 template=yes

Greetings and thank you very much

bommi · Thu Aug 01, 2024 9:44 am

Can you enable ipsec logging and try to establish the VPN?

johnb175a · Fri Aug 02, 2024 11:17 pm

I am having this exact same issue using IKEv2/IPSec PSK. This setup worked a few months back and when I went to use it recently the Android device (Samsung S24+) cannot ping the router or an device behind it. However, from the router and any device behind it on the LAN, I can ping the android device and get a reply. I've looked and cannot seem to figure out why this is happening. Hopefully someone here can point us in the right direction.

Bene007 · Sun Aug 04, 2024 9:58 pm

I have exactly the same problem. A connection can be established from the VPN client (Android 13, also Android 14 - IKEv2/IPSec RSA), but nothing can be reached either in the local network or on the Internet. Clients in the network can reach the VPN client.
No settings have been changed and no updates have been made recently.
It stopped working from one day to the next.

Edit:
I no longer use the native VPN in Android, but Strongswan instead. It works then again. However, it's still very strange.

doug993 · Wed Aug 07, 2024 6:16 pm

I have the same problem, has anyone found a solution to use the native android vpn client?

TheCat12 · Wed Aug 07, 2024 10:51 pm

If somebody could enable IPsec logging and post the log here, I would be glad to help:

/system logging
add action=memory topic=ipsec,!debug

TheCat12 · Wed Aug 07, 2024 10:55 pm

Personally, I use sha1, sha256, aes-256 and pfs-group=none for proposals and sha256, aes-256, modp1024 and modp2048 for profiles and it works for my native Android VPN client although I see that the OP uses the same configuration and it doesn't work for him, which is very odd. Perhaps an Android or ROS update broke something with the cryptography techniques

cristian1986 · Thu Aug 08, 2024 2:33 am

I have exactly the same problem. A connection can be established from the VPN client (Android 13, also Android 14 - IKEv2/IPSec RSA), but nothing can be reached either in the local network or on the Internet. Clients in the network can reach the VPN client.
No settings have been changed and no updates have been made recently.
It stopped working from one day to the next.

Edit:
I no longer use the native VPN in Android, but Strongswan instead. It works then again. However, it's still very strange.

Hi Bene007, can you share how can you connect with this configuration to strong swan? I need to keep this ipsec configuration, I can't upgrade to version 7 for other vpn options, I need to stay on version 6, thanks

Bene007 · Sun Aug 11, 2024 9:19 pm

The most important settings, next to the correct server address and VPN type, are entering the correct algorithm (you need to check "Advanced settings").
I guess you need to enter at the end of the settings the following:
IKEv2 algorithm
aes256-sha256

IPsec/ESP algorithm
aes256-sha256-sha1

johnb175a · Mon Aug 12, 2024 6:43 pm

If somebody could enable IPsec logging and post the log here, I would be glad to help:

TheCat12 · Mon Aug 12, 2024 8:21 pm

@johnb175a, in your case, the VPN tunnel establishes, so the problem is somewhere else. That's why I would additionally need a full export of the config:

/export file=anynameyouwish (minus sensitive info)

johnb175a · Mon Aug 12, 2024 9:46 pm

@johnb175a, in your case, the VPN tunnel establishes, so the problem is somewhere else. That's why I would additionally need a full export of the config:

/export file=anynameyouwish (minus sensitive info)

TheCat12 · Mon Aug 12, 2024 10:46 pm

You're missing a loopback address:

/ip address
add address=192.168.10.1/24 interface=lo1

*lo1 should be the name of recently exposed loopback interface, if not, please change "interface=" correspondingly

TheCat12 · Mon Aug 12, 2024 10:59 pm

Also, I don't see a policy template:

/ip ipsec policy group
add name=ikev2-policies

/ip ipsec policy
add dst-address=192.168.10.0/24 group=ike2-policies proposal=proposal1 src-address=0.0.0.0/0 template=yes

johnb175a · Tue Aug 13, 2024 4:58 am

/ip address
add address=192.168.10.1/24 interface=lo1

I get "input does not match any value of interface". I see a lo interface, but not a lo1.

TheCat12 · Tue Aug 13, 2024 11:58 am

I get "input does not match any value of interface". I see a lo interface, but not a lo1.

So the name is lo:

/ip address
add address=192.168.10.1/24 interface=lo

johnb175a · Tue Aug 13, 2024 5:52 pm

So the name is lo:
Code: Select all
/ip address
add address=192.168.10.1/24 interface=lo

Should I assign the IP to lo or create a bridge-loopback and assign it there? I was reading another article that seemed to indicate a bridge-loopback interface needed to be added with no members. It's so strange that this all worked without all these changes a while back. Although I am not sure if it was working before I jumped to 7.x or after.

TheCat12 · Tue Aug 13, 2024 7:24 pm

Should I assign the IP to lo or create a bridge-loopback and assign it there?

It's one and the same. The lo interface was exposed precisely to eliminate the need for a loopback bridge

It's so strange that this all worked without all these changes a while back. Although I am not sure if it was working before I jumped to 7.x or after.

Quite odd indeed, although changes regarding IPsec were introduced, of which I'm not fully aware.
If @Sindy could also have a look at your case, maybe she would find something obvious that I may be missing because I'm not sure whether my suggestions would make a change in your situation

johnb175a · Tue Aug 13, 2024 8:36 pm

It's one and the same. The lo interface was exposed precisely to eliminate the need for a loopback bridge

Ok, I applied all the changes you suggested but the problem persist. Any other things to try? I'm at a loss. It connects fine and passes traffic from the router and from machines behind the router to the android road warrior, but from the android road warrior to the router or anything behind it, nothing.

johnb175a · Wed Aug 21, 2024 10:28 pm

I've still had no luck with this. Anyone have any suggestions?

TheCat12 · Wed Aug 21, 2024 11:23 pm

Unfortunately I'm out of options. That's why I'll once again ask @sindy to have a look at your case

own3r1138 · Wed Aug 21, 2024 11:39 pm

Totally unrelated, but I could not stop myself.
@sindy, hope these make your ordinary day, extraordinary!

Screenshot 2024-08-22 000313.png

sindy · Thu Aug 22, 2024 10:21 pm

That's why I'll once again ask @sindy to have a look at your case

This forum does not support automatic notifications when someone mentions you so the only reliable way of paging someone is to find a recent topic to which that user has contributed and post an off-topic message there (usually with a reference to the topic you want them to assist with). For me in particular, @anav sometimes works as a relay but that only works with wireguard and topics dealing with policy routing and similar, not with IPsec.

To the topic - as usually when things don't work as expected, /tool/sniffer and ... print detail are your best friends.

So @johnb175a, once the IPsec connection from the phone establishes, try accessing something from the phone via the tunnel, and then run /ip ipsec installed-sa print detail. You should see something like
[me@myTik] > /ip/ipsec/installed-sa/print detail
Flags: S - seen-traffic; H - hw-aead; A - AH, E - ESP
0 SHE spi=0x177D7CC src-address=mikro.tik.wan.ip:4500 dst-address=cli.ent.nat.ip:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="bb632dfcfb10b66573032625d1bcc154c905eeab" enc-key="386854638be4bc197d2266a12a2cacb4a3017983ed5f877768b76a15947c4bd0" addtime=2024-08-22 12:48:19 expires-in=29m31s
add-lifetime=24m10s/30m13s current-bytes=17058 current-packets=108 replay=128

1 SHE spi=0xDE0E3E16 src-address=cli.ent.nat.ip:4500 dst-address=mikro.tik.wan.ip:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="d4847902b1fb47a424a2811c4059c8776fc48c99" enc-key="138985e1863a9a07e8354d571c7b5691bd8f39d825cff4742a93bca5217186cd" addtime=2024-08-22 12:48:19 expires-in=29m31s
add-lifetime=24m10s/30m13s current-bytes=328 current-packets=1 replay=128

Obfuscate only the IP addresses in the output and post it here - all the keys are ephemeral so once you disconnect the connection or 30 minutes elapse, whichever happens first, they become meaningless.

Also, post the output of /ip ipsec/statistics/print .

Loosely related - adding 192.168.10.1/24 to lo is one of possible ways how to make sure that some route to 192.168.10.0/24 exists in the system (you went too far with assuming what is relevant to your issue and what is not in your configuration, so from the configuration export you have posted it is not clear whether a default route exists in your system), but you have cerated a conflict -192.168.10.1 is also part of the pool you use to assign addresses to the IPsec initiators. So move the pool or move the own address so that they do not overlap, but the whole range in the pool must remain in the subnet defined by the own address and its mask. So e.g. 192.168.10.1/28 for own address and 192.168.10.2-192.168.10.6 for pool range are OK.

johnb175a · Fri Aug 23, 2024 12:06 am

/ip ipsec installed-sa print detail

Flags: S - seen-traffic; H - hw-aead; A - AH, E - ESP 
 0 S E spi=0xCE3600B src-address=1.2.3.4:56214 dst-address=5.6.7.8:4500 state=mature enc-algorithm=aes-gcm enc-key-size=288 
       enc-key="799494a783fde01832988a637a2b04047458a273b030f44bb4c7870982c159b77931f445" addtime=2024-08-22 15:57:12 expires-in=28m40s 
       add-lifetime=24m20s/30m25s current-bytes=46573 current-packets=315 replay=128 

 1 S E spi=0xCC3E4387 src-address=5.6.7.8:4500 dst-address=1.2.3.4:56214 state=mature enc-algorithm=aes-gcm enc-key-size=288 
       enc-key="7537f3cdcf7750f4928319f227cfc2d25635ddbc987b174079af4aeace468fe9062a5f23" addtime=2024-08-22 15:57:12 expires-in=28m40s 
       add-lifetime=24m20s/30m25s current-bytes=20344 current-packets=158 replay=128

/ip ipsec/statistics/print

                  in-errors: 0
           in-buffer-errors: 0
           in-header-errors: 0
               in-no-states: 233
   in-state-protocol-errors: 0
       in-state-mode-errors: 0
   in-state-sequence-errors: 1
           in-state-expired: 0
        in-state-mismatches: 0
           in-state-invalid: 0
     in-template-mismatches: 0
             in-no-policies: 0
          in-policy-blocked: 0
           in-policy-errors: 0
                 out-errors: 0
          out-bundle-errors: 0
    out-bundle-check-errors: 0
              out-no-states: 0
  out-state-protocol-errors: 0
      out-state-mode-errors: 0
  out-state-sequence-errors: 0
          out-state-expired: 0
         out-policy-blocked: 0
            out-policy-dead: 0
          out-policy-errors: 0

I also set the lo interface to 192.168.10.1/24 and the pool from 192.168.10.2 to 192.168.10.6. However when I configure it like that from a machine behind the router I can no longer ping the vpn client. I get TTL expired in transit. If I remove the lo interface I can then ping the client and get a reply, but the client can still not ping the router or any device behind it.

sindy · Fri Aug 23, 2024 4:02 pm

I can imagine that it is the fact that 192.168.10.1/24 is attached to lo in particular (rather than some other interface) that breaks the access to the client, but if you can ping the client and get a response when this idea of @TheCat12 is not used, it means that some other route to 192.168.10.x (probably the default one) is present in the system, which is all the IPsec needs.

Now open a command line window and make it as wide as your screen allows, connect the tunnel from the Samsung, start pinging an internal address x.x.x.x from it, and run /tool/sniffer/quick protocol=icmp ip-address=x.x.x.x in that command line Window.

If everything was OK, you should see the "echo" (ping request) packet to come in via WAN (because the payload packets extracted from IPsec transport ones inherit the in-interface attribute from them), then the same packet leaving via the bridge (as an IP interface) and then another time the same packet leaving via a particular member port of the bridge. Next, you would see the response from x.x.x.x to come in via the bridge port, and come into the IP stack via the bridge interface. The sniffer cannot show you the IPsec payload before encryption as it does not pass through any interface, so these five packets for each ping is the maximum you can see using sniffer. But I assume you will see either only the first one if the firewall on the Mikrotik is blocking the request (your export does not support this assumption) or only three if the device you ping is a Windows one with default firewall settings which say "only respond pings from your own subnet" for "private" networks and "ignore all pings" for "public" networks.

johnb175a · Fri Aug 23, 2024 4:38 pm

/tool/sniffer/quick protocol=icmp ip-address=x.x.x.x

I had to change this to /tool/sniffer/quick ip-protocol=icmp ip-address=192.168.1.2 as it would not accept just protocol=icmp in the above command.
192.168.1.2 is a windows machine with all firewalls disabled.

This is with the 192.168.10.1/24 assigned to the lo interface disabled. I wasn't sure if you wanted the test done with it enabled or disabled.

Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE        TIME   NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS   DST-ADDRESS   PROTOCOL  SIZE  CPU
ether1           0.411    1  <-   F8:F5:32:23:57:70  78:9A:18:4E:D1:DA  192.168.10.5  192.168.1.2   ip:icmp     98    2
bridge1-private  0.411    2  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           0.411    3  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           0.411    4  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
bridge1-private  0.411    5  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
ether1           2.557    6  <-   F8:F5:32:23:57:70  78:9A:18:4E:D1:DA  192.168.10.5  192.168.1.2   ip:icmp     98    2
bridge1-private  2.557    7  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           2.557    8  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           2.558    9  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
bridge1-private  2.558   10  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
ether1           4.668   11  <-   F8:F5:32:23:57:70  78:9A:18:4E:D1:DA  192.168.10.5  192.168.1.2   ip:icmp     98    2
bridge1-private  4.669   12  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           4.669   13  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           4.669   14  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
bridge1-private  4.669   15  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
ether1           6.794   16  <-   F8:F5:32:23:57:70  78:9A:18:4E:D1:DA  192.168.10.5  192.168.1.2   ip:icmp     98    2
bridge1-private  6.794   17  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           6.794   18  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.10.5  192.168.1.2   ip:icmp     98    2
ether5           6.794   19  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3
bridge1-private  6.794   20  <-   88:AE:DD:01:3C:FE  78:9A:18:4E:D1:DC  192.168.1.2   192.168.10.5  ip:icmp     98    3

This is with the 192.168.10.1/24 assigned to lo interface enabled.

Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE        TIME    NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS  DST-ADDRESS   PROTOCOL  SIZE  CPU
lo               24.36  2986  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2987  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2988  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2989  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2990  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2991  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2992  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2993  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2994  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2995  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2996  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2997  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2998  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  2999  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  3000  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  3001  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  3002  ->   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
lo               24.36  3003  <-   00:00:00:00:00:00  00:00:00:00:00:00  192.168.1.2  192.168.10.5  ip:icmp     98    3
bridge1-private  24.36  3004  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.1.1  192.168.1.2   ip:icmp    126    3
ether5           24.36  3005  ->   78:9A:18:4E:D1:DC  88:AE:DD:01:3C:FE  192.168.1.1  192.168.1.2   ip:icmp    126    3

sindy · Fri Aug 23, 2024 5:30 pm

I had to change this ...

Sorry, mea culpa.

I wasn't sure if you wanted the test done with it enabled or disabled.

Disabled, but never mind, we've smashed two flies with a single sweep. The less important one is that indeed IPsec treats lo differently from other interfaces so if you ever need to provide a route to the addresses that are ultimately accessible via IPsec peers, do not create it by attaching an IP address to lo.

The more important feedback we've got is that the 192.168.2.1 does respond and the response does come back to the Mikrotik; there are no weird issues with MAC addresses, and the firewall rules also seem fine to me (from the point of view of IPsec - from other perspectives the order of rules in forward effectively inhibits fasttracking, but that's another can of worms to deal with).

Given that pinging the Samsung from the Windows side works, I can't see how there could be any issue with the IPsec encryption.

So the next step is the following:
/ip firewall mangle
add chain=postrouting src-address=192.168.1.2 dst-address=192.168.10.0/24 protocol=icmp action=log log-prefix="plaintext icmp response"
add chain=output protocol=udp src-port=4500 action=log log-prefix="encrypted icmp response"

Instead of /tool/sniffer/quick ..., run /log/print follow-only where topics~"firewall" this time, ping 192.168.1.2 from the Samsung, and paste the output of the /log/print ... here (this time you'll have to obfuscate the public IPs again).

johnb175a · Fri Aug 23, 2024 6:19 pm

/log/print follow-only where topics~"firewall"

10:13:09 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:09 firewall,info plaintext icmp response postrou: in:bridge1-private out:ether1, connection-state:established src-mac 88:AE:DD:01:3C:FE, proto ICMP (type 0, code 0), 192.168.1.2->192.168.10.5, len 84 
10:13:09 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:10 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:10 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 136 
10:13:10 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:10 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:10 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:11 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 320 
10:13:11 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 144 
10:13:11 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:11 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:11 firewall,info plaintext icmp response postrou: in:bridge1-private out:ether1, connection-state:established src-mac 88:AE:DD:01:3C:FE, proto ICMP (type 0, code 0), 192.168.1.2->192.168.10.5, len 84 
10:13:11 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:12 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 304 
10:13:13 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:13 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:13 firewall,info plaintext icmp response postrou: in:bridge1-private out:ether1, connection-state:established src-mac 88:AE:DD:01:3C:FE, proto ICMP (type 0, code 0), 192.168.1.2->192.168.10.5, len 84 
10:13:13 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:15 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 176 
10:13:15 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:15 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 136 
10:13:15 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:15 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:16 firewall,info plaintext icmp response postrou: in:bridge1-private out:ether1, connection-state:established src-mac 88:AE:DD:01:3C:FE, proto ICMP (type 0, code 0), 192.168.1.2->192.168.10.5, len 84 
10:13:16 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148 
10:13:16 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 320 
10:13:16 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 144 
10:13:17 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 224 
10:13:17 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124 
10:13:17 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 304 
10:13:18 firewall,info plaintext icmp response postrou: in:bridge1-private out:ether1, connection-state:established src-mac 88:AE:DD:01:3C:FE, proto ICMP (type 0, code 0), 192.168.1.2->192.168.10.5, len 84 
10:13:18 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 148
10:13:18 firewall,info encrypted icmp response output: in:(unknown 0) out:ether1, connection-state:established proto UDP, 1.2.3.4:4500->5.6.7.8:35968, len 124

sindy · Fri Aug 23, 2024 6:45 pm

I'm afraid we have exhausted all diagnostic steps we could use at Mikrotik side. In the log, every plaintext packet of 84 byte size is followed by an IPsec transport packet of 148 byte size, and there is no reason why encryption of the ICMP responses should differ from encryption of other payload packets. So the only explanation I can imagine is that the application you use to ping on the Samsung has some issue. At least such explanation is about as crazy as the ISP disliking 148-byte packets or the Mikrotik encrypting the 84-byte ping responses in a way that the IPsec stack on Samsung does not like.

So you can disable or remove the mangle rules, and proceed by praying or cursing as per your personal preferences. Do you have a chance to try with another Android phone? Do you use a native VPN client on the Samsung or something else?

@TheCat12, on top of the above, the case brought in by @johnb175a is very different from the other two.

johnb175a · Fri Aug 23, 2024 6:55 pm

So you can disable or remove the mangle rules, and proceed by praying or cursing as per your personal preferences. Do you have a chance to try with another Android phone? Do you use a native VPN client on the Samsung or something else?

It's not just ICMP. I tried to VNC and RDP onto the 192.168.1.2 machine from the Samsung VPN client and nothing. Yes, I am using the native Android VPN client. This exact setup did work a while back. I can try from another android device. This is so strange to me. So in your opinion the VPN tunnel is working correctly? It's strange that 192.168.1.2 can ping 192.168.10.5 and get a response, but 192.168.10.5 cannot get a response from 192.168.1.2 or any other workstation behind the router.

sindy · Fri Aug 23, 2024 7:10 pm

This is so strange to me.

Same here. All explanations I can imagine seem equally crazy to me.

So in your opinion the VPN tunnel is working correctly?

On Mikrotik side, yes. It receives the transport packet carrying the request, decrypts it, extracts the plaintext payload, delivers it to the destination, gets a response (so the request must have been decrypted correctly), routes it, the IPsec stack catches it, encrypts it, and sends it to the Samsung.

johnb175a · Fri Aug 23, 2024 7:22 pm

Do you have any recommendations for a third party vpn client I can try on the Android? Something you are familiar with maybe. I would like to get something to work. I thought I read somewhere about strongSwan working, but I can't find it and also have no experience with it.

sindy · Fri Aug 23, 2024 7:47 pm

I do use Strongswan on my Android phone - https://play.google.com/store/apps/deta ... an.android .

It also has its caveats (if you want to access multiple remote subnets, you have to configure that in the client), but what may be most complicated for you is the authentication. The Android version only supports IKEv2, and you can choose between

having to create a certificate for the phone and installing it there
having to install user-manager on your Mikrotik device (which may or may not be possible depending on its flash size, i.e. your particular device model) or using any external RADIUS server to allow username&password authentication

The remaining authentication models are even more complicated than these two.

Since you're running ROS 7.15.something, you can use Let's Encrypt to get a certificate for the Mikrotik itself, it only requires that an FQDN would resolve to your public address, so in the worst case you can use the Mikrotik cloud one or even nip.io that resolves any fqdn in the form ip.add.re.ss.nip.io (and multiple other ones) to ip.add.re.ss.

But if you want to go further this path, please open a separate topic for that, we've got really far away from the OP's scenario and issue.

TheCat12 · Fri Aug 23, 2024 8:20 pm

@TheCat12, on top of the above, the case brought in by @johnb175a is very different from the other two.

Guilty.

When I looked at the config and the IPsec exports and everything seemed normal, I had to call you in as an IPsec expert.

As for the OP's problem, I think I might have found the culprit and it is indeed Samsung:

https://r2.community.samsung.com/t5/Gal ... p/16749697

sindy · Fri Aug 23, 2024 10:00 pm

Guilty.

Nope, turns out it's me who has commited diagonal reading - the OP's issue is actually the same like @johnb175a's, except that the OP did not take as much effort to analyse it as @johnb175a

johnb175a · Fri Aug 23, 2024 10:14 pm

Hey, I try my best. What can I say. So it looks like it's an Samsung/Android issue. From reading the post it looks like it assigns a /0 mask instead of a /32 to the client. Is there a way to make strongSwan work without going the certificate route? I really would prefer to just use a PSK. I am running a hAP ac3 (RBD53iG-5HacD2HnD).

TheCat12 · Fri Aug 23, 2024 10:36 pm

Is there a way to make strongSwan work without going the certificate route?

The only other way is configuring User Manager (your router has a beefy flash, so no worries for installing) which could be or could be not more complicated to set up. But let's try anyway.

Here you can read what the prerequisites are (spoiler: a Let's Encrypt certificate and installed User Manager) and how to configure everything:

https://help.mikrotik.com/docs/display/ ... outerOSv7)

In this case I think you won't need to install strongSwan

sindy · Fri Aug 23, 2024 11:26 pm

In this case I think you won't need to install strongSwan

As in "the Samsung bug is only related to PSK authentication", which the thread dealing with that bug suggests. It implies that the same stock VPN client that fails to work with PSK should behave properly if using other authentication methods, such as username/password to authentify the client to the server and a certificate to authenticate the server to the client, which is the simplest way you could get with Strongswan.

Is there a way to make strongSwan work without going the certificate route?

On Android, no.

I am running a hAP ac3 (RBD53iG-5HacD2HnD).

128 MB of flash are sufficient to run user-manager.

johnb175a · Sat Aug 24, 2024 12:40 am

What would you recommend as the simplest option to get a working connection from Android to the Mikrotik? Would it be to use the native VPN client or strongSwan?

sindy · Sat Aug 24, 2024 1:45 am

What would you recommend as the simplest option to get a working connection from Android to the Mikrotik? Would it be to use the native VPN client or strongSwan?

You can try with the native client, and if it still does not work, install Strongswan. The steps of installing a Let's Encrypt certificate and installing and configuring user-manager are the same for both cases and they require far more clicks than the installation of Strongswan to the phone.

johnb175a · Tue Aug 27, 2024 11:45 pm

Just wanted to give an update. I hadn't had a chance to install user-manager or setup the cert, but I just checked back on the Samsung link above and the last reply was a user stating he rebooted and the VPN magically worked. I've rebooted my S24+ many times over the diagnosis period with no luck and thought surely this couldn't be. After reading the post, I decided to reboot again today. Lo and behold the VPN connects like it always has, but now I get replies from the router and machines on the LAN. No updates were installed, just like the user posted on the Samsung site. Somehow, magically it started working. This is very strange. I've connected and disconnected several times, and it continues to work.

sindy · Wed Aug 28, 2024 9:03 am

No updates were installed, just like the user posted on the Samsung site. Somehow, magically it started working. This is very strange.

Somewhere at the beginning of that Samsung thread someone said that these "security updates" are downloaded in the background and installed without asking at reboot. So they broke it weeks/months ago this way, and now they fixed it this way.