Newest problem is as follows if you can point me out to what is causing this issue.
I have an L2TP with IPSEC server running on a MikroTiK RB4011.
I can connect from an android device using LTE to the L2TP without any problems BUT if the device switches to WIFI and tries to connect it fails miserably.
I read somewhere that i have to change the generate policy from port strict to port override but it creates dynamic rules which i can’t change and i can’t seem to figure out
how to add it manually and point it to the L2TP server on 6.46.x version.
On the RB4011 there is also a working IPSEC site to site tunnel.
/ppp profile
add bridge=bridge1 dns-server=8.8.8.8 local-address=192.168.0.254 name=
l2tp_ipsec remote-address=vpnpool use-encryption=required
/ppp secret
add name=admin password=xxxxxxxx profile=l2tp_ipsec service=l2tp
/interface l2tp-server server
set allow-fast-path=yes authentication=mschap1,mschap2 default-profile=
l2tp_ipsec enabled=yes ipsec-secret=xxxxxxx keepalive-timeout=disabled
max-mru=1460 max-mtu=1460 use-ipsec=yes
/ip firewall filter
add action=accept chain=input dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment="IPSec enable " protocol=ipsec-esp
i can’t seem to figure out how to add it manually and point it to the L2TP server on 6.46.x version.
You will have to create an IPsec in transport Mode, not tunnel mode, manually and then create your L2TP Tunnel over the IPsec and then add the appropriate routes…
This way you actually do what the L2TP/IPsec would do automatically…
BUT if the device switches to WIFI and tries to connect it fails miserably.
Is the Android phone connected to the WiFi provided by the very same 4011 which is the L2TP/IPsec server, or is it provided by the same Mikrotik which itself is a peer of the site-to-site IPsec tunnel, or is it totally unrelated to either of them?
Is the site-to-site tunnel an IKE(v1) or IKEv2 one?
I don’t think port override would change anything. You can create the IPsec settings for an L2TP server, ideally by letting the /ip l2tp-server server create the peer and identity, and then copying them with the same parameters: ip ipsec peer add copy-from=l2tp-in-server name=l2tp-in-static
ip ipsec identity add copy-from=[find comment~“l2tp”] peer=l2tp-in-static
The static peer will be shadowed by the dynamically added one until you disable the auto-creation in /interface l2tp-server server.
Then, you can completely customize the settings - use a different profile for the peer, choose a different policy-generation method and policy-generation template group in identity, so you can use a different policy template with a different proposal. But I bet none of these will resolve the issue, as the Android phone itself has no reason to change the behavior of the VPN client depending on the network interface it uses.
the packet is retransmitted about 5 times then phase1 negotiation failed
i tried creating it manually but i must be doing something wrong i dial in and it says established but the phone still tries to connect (shows connecting instead of connected) then fails.
I obviously must be doing it wrong i have to try and find out how to make it in transport mode.
Which “the” packet? The first response one from the Mikrotik to the phone or one of the later ones?
I’ve seen multiple cases recently which behaved similarly - the initial negotiation failed at some stage. In one case it boiled down to packets being too large and fragmented, in the other one I’ve got no feedback yet, these were both related to certificate-based authentication. Another case was also L2TP/IPsec, and it seemed to have to do with Android version, but no one has ever stated anything regarding WiFi or mobile connection of the mobile.
21:34:18 ipsec,info respond new phase 1 (Identity Protection): 192.168.1.235[500]<=>xxxxxxxxxxx[500]
21:34:21 ipsec,info the packet is retransmitted by xxxxxxxxxxxxx[500].
21:34:24 ipsec,info the packet is retransmitted by xxxxxxxxxxxxx[500].
21:34:27 ipsec,info the packet is retransmitted by xxxxxxxxxxxxx[500].
21:34:30 ipsec,info the packet is retransmitted by xxxxxxxxxxxxx[500].
21:34:33 ipsec,info the packet is retransmitted by xxxxxxxxxxxxx[500].
21:34:48 l2tp,info first L2TP UDP packet received from xxxxxxxxxxxxxx
21:35:18 ipsec,error phase1 negotiation failed due to time up 192.168.1.235[500]<=>xxxxxxxxxxx[500]
Correct. Setting use-ipsec to no in /ip l2tp-server server will not prevent actual use of IPsec but it will just prevent the dynamic IPsec configuration from being created. The dynamically created one uses the default peer profile, default proposal, and creates the identity with generate-policy set to port-strict. Creating these two items manually allows you to customize them, to test whether the generate-policy=port-override will resolve the issue.
If this change doesn’t help as I assume, I’d recommend you set /tool sniffer set file-name=android_startup.pcap, run /tool sniffer ip-address=the.public.ip.of.the.WiFi.where.the.phone.is.connected while you run the log (/log print follow-only file=android_startup where topics~“ipsec”) and do a connection attempt from the phone.
This will show you whether the packets towards the phone actually leave the Mikrotik and if yes, which route they take. The dump on the screen will show the physical interfaces; the pcap file will allow to analyse the packets in Wireshark.
the Mikrotik sends the responses back to the mobile but they apparently never reach it, as it keeps re-sending the first packet, so the next question is whether they are leaving through the right interface (which is what the first column of the command line output of /tool sniffer quick should show you)
the size of the response packet is so small that the “lost fragments of a huge packets” theory is obviously not applicable
the L2TP connection was about to set up without being protected by IPsec. To prevent this from happening, you have to add a rule chain=input action=drop protocol=udp dst-port=1701 ipsec-policy=in,none before the chain=input action=accept connection-state=established,related one, because you want the L2TP to break also if the IPsec eventually stops working mid-session.
By any chance, can you sniff at the AP to which the Android phone is connected?
Asked my neighbour to access his WiFi abit and the same thing happens to me also…i can connect via my 4G and not via WiFi so this happens at 2 different locations. Both Androids have 9.0.
Ipsec Server 6.46.5.
I am having my suspicions that there could be elevated firewall policies that have to be disabled from the ISP side as far as the HQ is concerned…
That might be it… do you want me to give a try from my 8.1.0? If so, I can send you my public key and instruction how to use it to send me the contact information via a forum post securely. The test account may get an address blocked by firewall so it wouldn’t get anywhere.
Also, think about installing Strongswan on the phone(s) and using IKEv2.
Selective policies depending on the remote IP, and blocking the direction from the client (the HQ) to internet after letting the packet from the internet to the client through? That would be a really exotic approach…
As your own phone suffers from that problem too, maybe you could connect it to your home AP and place that AP behind the home Mikrotik, so that you could sniff on it to see whether the packets get dropped on the path between the HQ and the client’s WiFi AP or whether they make it (almost) to the phone?