We have had a tunnel up for over 5 years using L2TP and IPsec between two RB4011iGS+ with no issues.

This morning, without any reason, my log was filled with: "phase1 negotiation failed due to time up ....." and the connection will not establish. The calling side is just sitting there with a "waiting for packets..." message. We have rebooted everything and are running 7.14.2 on both routers.

The actual error message is: "phase1 negotiation failed due to time up x.x.x.x[500]<=>y.y.y.y500] 53734ac3cb3e9e8a:6030c1d61b3ea9ac"

*(public IP's are x/y)


We have had no configuration changes in almost a year.

Has anyone seen this before?

-Scott

Yes. This is caused by NAT issues in an ISP router that sits in front of your MikroTik.
Restart that. You can also sometimes avoid it by configuring the MikroTik as "DMZ host" in that ISP router.

Thanks for your fast response.

This remote router is on a Comcast internet connection. I do not have access to that router. Any additional suggestions?

By the way, other L2TP connections from individual users (like from iPhone) is still working... only the Mikrotik-Mikrotik connection is broken.

-Scott

It often helps when you disable the L2TP link for ~10 minutes so all NAT entries in the ISP router get cleared out.
Other than that, there is little that can be done.

When other users behind the same router have L2TP to your "central" MikroTik router, there is your reason: the MikroTik router will only be able to setup a connection when it is the first L2TP between that IP pair.

The problems started in the middle of the night when no other users (except for the persistent connection between MT router) was/were active.

We did have an issue a long time ago when version 7 first came out that prevented multiple users behind the same router from connecting; however, that was resolved and frequently we have the core router and multiple users connected at the same time without any issues.

-Scott

I shut the connection for almost an hour with no improvement. Maybe I need to totally drop the entire router connection for a while???

Comcast (Xfinity) is serving me a dynamic public IP. Is NAT still being used on their end even-though it looks like I have public IP.

-Scott

For some reason the L2TP/IPsec link will only work when the port number 500 is passed on without translation, and when the ISP router sees more than one IPsec connection it will change the port number and you will not be able to get it working again until the conflicting NAT entry has been deleted.

I have suggested a couple of ways to do that, but I cannot help you when those do not work.
(I have had these issues as well, and setting the MikroTik as the DMZ host solved that as that means it will reserve the untranslated entry for that host)

So, problem now solved. I took your advice and shut things down for a while (about 1 hour +-), When I brought things back up, a new dynamic IP was assigned. This is not always the case, but okay. After making a few adjustments on the client side's firewall for the new IP, the PPP interface came right back up with no issues or configuration changes of any type. I am not exactly sure what fixed that problem, but I'm happy.

@pe1chl Thanks for the suggestions!

-Scott

Did you try just rebooting the Comcast router without shutting it down for an hour? Usually it would be enough, at least for me it is with AVM Fritzbox routers that we have on our local ISP which assigns a static address to each subscriber.
The NAT table issue in the Fritzbox is then cleared. It can be made more reliable by configuring a static mapping or DMZ in the Fritzbox.
(static mapping would be for port 500 and 4500 UDP to be mapped to an internal address, the address of the MikroTik)

But maybe in your case there is NAT or stateful firewall further down in the Comcast network and it can only be solved by getting a different IP address.
There are long writeups on the forum about the problem of having more than one L2TP/IPsec user on the same IP pair, which happens when you have multiple users behind the same NAT.
Your mention of recent v7 versions suggests that it may have been solved, but I had not read that yet on the forum, I would have to test if that really is the case.