i have a weird L2TP/IPSec user access problem.
two of our client’s employees connects from different country(DE IP, not blocked). one is completely OK, the other has problems. every(including these ones) employee uses its own L2TP secret.
employee1 - secret1 works without problems
employee2 - secret2 does not work (he can connect create the VPN connection, but can’t access the local network, because it is not answering, even the ping)
employee2 - testsecret works
employee2 - secret1 and secrets3-10 works
testuser - testsecret works
testuser - secret2 works
employees3-10 - secrets3-10 works
saw in logs(not anymore there, so i can’t copypaste it) that employee2’s L2TP connection was terminated without proper disconnection(can’t remember the exact log entry) todays morning. since then he couldn’t connect on secret2. i have to change it to secret3. now he can access mikrotik’s local network from outside of the country via VPN. Tx connection answers Rx requests correctly.
is there any internal IP blocking list of L2TP connections that i can’t find? i have no entry in access list to block employee2 public IP address.
when you mention a secret, you have in mind a row in the /ppp secret table, correct?
when you say that “testuser - secret2” works, it means that the testuser uses the same username and password as employee2, so he lands at the same /ppp secret row?
did I get you right that employee2 was successfully using secret2 for some time, then “something” happened, and since then he can connect using credentials matching any other /ppp secret row but not his “own” one?
So what you suspect is that there is a link between the IP address of the client and the /ppp secret row, which prevents employee2 from connecting from the same public IP while using that row of /ppp secret.
If all the above is correct, what does /interface l2tp-server print detail show when no one currently attempts to use secret2? Is there anything related to secret2?
If not, create the supout.rif (/system sup-output name=some-name) so that you could demonstrate the state to Mikrotik support. Then, delete the secret2 row and note down any error message you may get. Then, create it again with the same contents, and let employee2 try again with the credentials matching secret2.
If he can connect after this, send the description (or just a link to this forum topic) to support@mikrotik.com (or use https://help.mikrotik.com) along with the .rif file you’ve created.
If you can see some relict, post here what it shows, replacing the public IP for anonymity reasons.
yes, testuser is my random testing account and uses the same secret(login account) as employee2. and the top of that is, that i even tried to use the secret2 at the same time from my 2 VMs(virtual machines) and it worked on both of them
yes, until yesterdays morning he was able to use the secret2 without any problems. but no, he CAN connect, yet he receives nothing. communication from him to mikrotik works, but mikrotik does not answer. looks like it is blocked somewhere and i can’t find the issue. and yes to the last part - he can use other secrets normally but his own secret2
[user@MikroTik] > /interface l2tp-server print detail
Flags: X - disabled, D - dynamic, R - running
0 DR name=“” user=“employee2” mtu=1400 mru=1450
client-address=“1.2.3.4” uptime=3h48m48s
encoding=“cbc(aes) + hmac(sha1)”
[user@MikroTik] >
luckily(or unluckily) the employee2 is connected right now with secret3. he needs to work and this is the only working workaround. so → no, there’s noone connected on secret2. plus unluckily for me, it is hard to dig what is going on, because i can’t reproduce his problem.
i recreated the secret2 ppp secret and asking customer to try it on his computer at the moment. will get back later.
If you haven’t created supout.rif before removing the secret2, Mikrotik will not be able to see the issue and thus won’t be able to fix it. So if it happens next time, don’t forget to create the .rif, at best one while the user is connected and cannot send packets, and another one while the user is not connected.