respond new phase 1 (Identity Protection): 40.18.134.183[500] <=> 77.204.247.91[1525]
the packet is retransmitted by 77.204.247.91[1525].
the packet is retransmitted by 77.204.247.91[1525].
the packet is retransmitted by 77.204.247.91[1525].
the packet is retransmitted by 77.204.247.91[1525].
the packet is retransmitted by 77.204.247.91[1525].
first L2TP UDP packet received from 77.204.247.91
phase1 negociation failed due to time up 40.18.134.183[500] <=> 77.204.247.91[1525]
First it would be best if you post your whole config with hide-sensitive… Also, hide your Public IP on your previous posts…
Why do you change the MSS ? You can select that option on your L2TP profile anyways…
Also look here:
“phase1 negotiation failed due to time up” what does it mean?
There are communication problems between the peers. Possible causes include - misconfigured Phase 1 IP addresses; firewall blocking UDP ports 500 and 4500; NAT between peers not properly translating IPsec negotiation packets.
This error message can also appear when local-address parameter is not used properly. More information available here.
Source: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Basic_L2TP.2FIPsec_setup
First it would be best if you post your whole config with hide-sensitive… Also, hide your Public IP on your previous posts…
I have already anonymous my configuration.
Why do you change the MSS ? You can select that option on your L2TP profile anyways…
It was just a simple help of my association network provider.
There are communication problems between the peers. Possible causes include - misconfigured Phase 1 IP addresses; firewall blocking UDP ports 500 and 4500; NAT between peers not properly translating IPsec negotiation packets.
Okey, but it seems to be the forward chain problem.
I don’t get the remark about forward chain. Whether a received packet will take the input chain or the forward chain depends on its destination address. If it is any of router’s own addresses, it takes the input chain; if it is any other one, it takes the forward chain. However, dst-nat takes place before this decision is taken, so a packet coming to one of the own addresses of the router can be redirected to another destination address, so it then goes via forward chain (and vice versa). But your partial configuration export contains no action=dst-nat rules whilst you mention some “redirection L2TP0” - what is that?
Plus I cannot see in your partial config export neither use-ipsec=yes in the /interface l2tp-server server configuration nor a manual configuration of an IPsec peer, policy etc.
The log is somehow too sparse - it mentions that the IPsec engine has received the initial packet from the mobile device, and then only reports retransmissions but nothing regarding the answer your own device sends (or why it doesn’t). So if you did configure the IPsec one way or the other, use
Then run /log print follow-only file=l2tp_startup where topics~“ipsec|l2tp” and try to connect the client again. Once it fails, stop the /log print and download the file. The regular log file may be to small to hold all the messages as you’re already running two L2TP connections so their control messages will fall into the log as well.
If you haven’t configure the IPsec in either of the two possible ways, the log should complain about missing information necessary to process the incoming request, but it never came to my mind not to configure anything about IPsec and attempt an incoming IPsec connection.
Also, the same IP address as source one of the incoming traffic from the Android device and as the destination one of your L2TP client tunnels is very confusing.
