I have a L2TP/IPsec server set up. When connecting to it from my Android phone on LTE (important!) the log in my router has this:
respond new phase 1 (Identity Protection): MY-IP[500]<=>PHONE-IP[57803]
ISAKMP-SA established MY-IP[4500]-PHONE-IP[57801] spi:junk-here:junk-here
but there’s nothing else. When connecting to the server on the local network, it works just fine. It seems like I can’t get past phase 1, and I suspect that this has to do with the CGNAT that my phone’s exposed to. The nat-traverse setting in IPsec is already turned ON, so that’s no help. Finally, in IP → IPsec → Active Peers, I see that a connection is made with my phone and the router receives a lot of packets but sends none out.
Is there a fix?
I wouldn’t think it’s the CGNAT, rather some fragmentation issues. Activate more detailed logging on the Mikrotik and try again:
/system logging add topics=ipsec,!packet
/log print follow-only file=ipsec-start where topics~“ipsec”
then start connection attempt from the phone. Once it fails, break the /log print, download the file and see what it says (or post it after replacing your public IP as suggested in my automatic signature below).
Here’s the debug file. At the beginning there’s a mention of fragmentation, and at the end I found some “authtype mismatch: me:cipher peer:cipher.” Is there any useful info here? ipsec-start.txt (67.3 KB)
The chain of mismatches ends by a match, so it is not relevant. Also the FRAGMENTATION mentioned in the log means that fragmentation of the IKE negotiation packets is supported, i.e. it is not a complaint about existence of fragmented packets.
The log shows that both Phase 1 and Phase 2 have completed successfully: 09:18:40 ipsec IPsec-SA established: ESP/Transport MikRouter[4500]->*Phone[51233] spi=0xd6631ba
Next, the IPsec stack sends keepalive (KA) packets every 20 seconds:
09:18:41 ipsec,debug KA: MikRouter[4500]->*Phone[51233]
09:18:41 ipsec,debug 1 times of 1 bytes message will be sent to *Phone[51233]
09:19:01 ipsec,debug KA: MikRouter[4500]->*Phone[51233]
09:19:01 ipsec,debug 1 times of 1 bytes message will be sent to *Phone[51233]
09:19:21 ipsec,debug KA: MikRouter[4500]->*Phone[51233]
09:19:21 ipsec,debug 1 times of 1 bytes message will be sent to *Phone[51233]
It is normal that no response comes for these, and it has no consequences.
Then, the phone actively terminates the IKE session: 09:19:38 ipsec,debug ===== received 108 bytes from *Phone[51233] to MikRouter[4500]
09:19:38 ipsec,debug receive Information.
09:19:38 ipsec,debug hash(sha2_256)
09:19:38 ipsec,debug hash validated.
09:19:38 ipsec,debug begin.
09:19:38 ipsec,debug seen nptype=8(hash) len=36
09:19:38 ipsec,debug seen nptype=12(delete) len=16
09:19:38 ipsec,debug succeed.
*09:19:38 ipsec,debug Phone delete payload for protocol ESP
So
run /system logging add topics=l2tp
open two more terminals (cli windows)
in one cli window, run /tool sniffer quick port=4500
in another cli window, run the /log print follow-only … and repeat the connection attempt
20-40 seconds after starting the connection attempt, run /ip ipsec policy print detail in the third window
after the connection attempt fails, stop the /log print … and /tool sniffer quick …
run /tool sniffer packet print within a minute after stopping the /tool sniffer quick …
download the log file, anonymize it, and post it here together with the output of the /ip ipsec policy print and /tool sniffer packet print
A problem at L2TP level seems unlikely as it works from LAN, but I want to see what’s going on there. What is more likely is that the mobile operator’s firewall closes the pinhole too fast so part of the packets from the Mikrotik do not make it to the phone. And what is also unlikely but possible is that the Mikrotik doesn’t actually send them - that’s why I ask for the /tool sniffer packet print.
Show me the complete export of your configuration (see my signature below regarding anonymisation). It seems that a firewall rule is missing in your configuration, as the sniffer shows that the phone is sending encrypted packets between the keepalives but there is no l2tp row in the log.
When you connect via LAN, the rule action=accept chain=input in-interface-list=WAN port=500,17031701,4500,5500 protocol=udp
is not necessary because the IPsec connection is established via LAN and thus the rule action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
does not drop the packets which need that permissive rule above if they come via WAN.
SOLVED! Switching the port to 1701 now gives me a “Connected” message in my phone. Also, as a side note, that last rule to drop all “WAN not DSTNATed” is listed with 0 packets and 0B in my firewall list. This is weird, considering that I have so many NATted services.
There’s nothing weird about that - the rule counts if it matches and thus drops a packet. Whatever is dstnated does not match the rule, so it doesn’t count.
And I’ve referred to a wrong rule in my previous post - the one which was dropping the L2TP packets coming (IPsec-encrypted) through WAN was the add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
one.
Another problem I noticed that is that some firewall rule is blocking me from accessing the router with L2TP, and I know it’s one of those two you mentioned, but I’m not sure how to fix it.
The reason is that once the L2TP client connects, RouterOS dynamically creates an interface called , through which the traffic from the client comes in. This interface is not a member of interface list LAN, so in the absence of any permissive rule, the rule action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
drops any packet coming in via that interface.
The easiest fix, if you don’t mind that the firewall will treat the L2TP client exactly the same way like LAN clients, is to run /ppp profile set default interface-list=LAN
After you disconnect and re-connect the client, the interface will be added as a member to interface list LAN.
If you want to use more specific firewall rules for the L2TP clients, you have to create a separate interface list and let the specific permissive rules match on it.
