![](/uploads/1/2/7/5/127535085/553250708.jpg)
Jerry Roy on Mikrotik L2TP / IPsec VPN Server Step by Step configuration with Fasttrack enabled! Damyan on Mikrotik L2TP / IPsec VPN Server Step by Step configuration with Fasttrack enabled! Frank Pikelner on Migrating opensource Zimbra 8.6.0 on Centos 6.8 to Zimbra 8.7.1 on Centos 7 safely and with no downtime! Today, I am going to share with us on how to set up Mikrotik site to site Ipsec VPN. Assuming you have a branch office that needs to connect to the head office for ease of communication and file sharing, then you need a VPN connection.
Troubleshooting a MikroTik VPN configuration can be frustrating if you do not know where to look. This article is specificly about troubleshooting L2TP over IPSec Remote Access VPNs on RouterOS.Below are RouterOS configuration areas that relate to L2TP over IPSec. Click to EnlargeHere are the steps to verify and troubleshoot Remote VPN connections to a MikroTik Router using L2TP over IPSec. Ensure that proper firewall ports are open –. Verify that the L2TP server is enabled. IPSec secret matches on router and client.
Verify that a compatible IPSec proposal is configured. Verify that PPP Profile and IP Pool is configured. Make sure PPP username/password matchesIs your L2TP Server Enabled?
Verify IPSec secret (PreShared Key). In Winbox, click PPP Interfaces L2TP Server.
x Enable should be checked. Use IPSec: yes. Set IPSec Secret: your-ipsec-pskVerify IPSec proposal. In Winbox, click IP IPsec Proposals.
Double click default. Auth Algorithms: x sha1. Encr. Algorithms: x aes-192-cbc, x aes-256-cbcNote: The above proposal is compatible with iOS iPhones / iPads.If you must support clients older operating systems (such as Windows XP), a different proposal may be required.
Verify PPP Profile & IP Pool. In Winbox, click PPP Profiles. Default a Local Address. Specify VPN IP Pool.
![Mikrotik L2tp Ipsec Site-to-site Mikrotik L2tp Ipsec Site-to-site](/uploads/1/2/7/5/127535085/344118591.png)
If a IP pool needs to be create, goto.IP PoolVerify PPP credentialsVPN username accounts are defined in RouterOS as PPP Secrets.PPP Secrets Enable IPSec logging.
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.I don't think port override would change anything. 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.I don't think port override would change anything. Does the log say anything when you try to connect through WiFi? The packet is retransmitted about 5 times then phase1 negotiation failedWhich '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.
The packet is retransmitted about 5 times then phase1 negotiation failedWhich '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. So static IPSEC entries mean /ppp l2tp-server enabled but without the use of ipsec in that menu?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=androidstartup.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=androidstartup 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. So static IPSEC entries mean /ppp l2tp-server enabled but without the use of ipsec in that menu?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=androidstartup.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=androidstartup 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. OK, so you can see three things from there:.
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? OK, so you can see three things from there:. 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?No unfortunatelly.the other side has no Tik's or anything. Just an ISP router where the android phone connects to it via the onboard WiFi. No unfortunatelly.the other side has no Tik's or anything. Just an ISP router where the android phone connects to it via the onboard WiFi.Hm.
What's the Android version? My 8.1.0 'Just Works' via both 4G and WiFi.
The L2TP/IPsec server is 6.44.6.The ISP blackbox may have its own IPsec handling which interferes with IPsec connections from LAN.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. 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.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? 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.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?My home Mikrotik belongs to the site to site range 192.168.5.0/24 that we discussed in our previous posts.
Won't that cause an issue?But you can give a try connecting to the HQ.i will contact you tomorrow so we can give it a go.
![](/uploads/1/2/7/5/127535085/553250708.jpg)