@erchegov and company, I was curious about your L2TP/IPsec issue here, so I’ve configured a network of four CHRs the following way:
CHR-47 is a L2TP/IPsec server running ROS 6.47, with several WAN IPs in the same subnet
CHR-3 is a “client router” whose WAN is connected to CHR-47’s WAN and does a src-nat for out-interface-list=WAN
CHR-1 and CHR-2 run and L2TP/IPsec client interface each, connecting each to another WAN IP of the CHR-47’s, connected as LAN hosts of the CHR-3
I believe this is a copy of your configuration - two clients connecting from behind the same “public” IP to the same server, but each to another public IP of the server.
CHR-1, CHR-2, CHR-3 all run 6.45.9.
The result is no fault found. Both clients connect, get their IP addresses, and are pingable through the tunnels. Both the IPsec security associations carrying the L2TP sessions have the same dst-address (the WAN IP of CHR-3), but they are distinguishable from one another by the server side IP addresses. Can someone of the affected gentlemen spawn a dedicated topic for this issue, post the export of their working server-side configuration there, and post a link to that new topic here in order to offload the current topic from this rather specialized discussion?
@sindy they are having issues with plain L2TP without IPsec encryption. I can confirm there is an issue but I am still struggling to reproduce the issue in a controlled environment even with all the debug information and configurations provided to me.
How about creating four builds – each with one of the four L2TP changes in the changelog reverted. Then, those of us having the issues can test and confirm which change introduced the issue. That could then help you focus your investigation.
The only other suspicious change is “*) interface - improved system stability when receiving bogus packets.” Without more insight into what exactly that change is referring to, I have no Idea if it could be related.
i had some wireless problems with this version, my battery powered wireless devices (phones, tablets, ipad) started to drain battery fast, i had to rollback to 6.46.6 to fix that. my setup is a hap ac2 as capsman manager/cap and a cap ac as a cap, here’s more info
Or adding new one. You simply cannot edit/create ipsec policies using winbox on 6.47. Winbox just crashes without any error message.
Update: Mea culpa. I thought I had the latest Winbox (3.24) but I made a mistake replacing the target file of my shortcut. It works OK with Winbox 3.24.
+1, although it looks like there will be a 6.48beta b/c they need to have one in order to introduce point releases for 6.47. It is probably not a big deal for them to do this because most of the fixes can be rolled up into v7, which is fine, and so it benefits both versions. I would just rather not have to wait another few years to see the topic “v7.00 [stable] is released!”
thaaats interesting. I just recreated from scratch our site-to-site VPNs on 2 routers running 6.47 and there was no crash.
Are you using latest winbox? there must be something particular triggering the bug.
To be specific - I opened old policies (migrated from 6.45), then deleted them (including all peers and peer identities) and created new ones (several times, because I have really bad knowledge of ipsec). I also tried to open and copy dynamic policies, peers and peer identities created by EoIP . All worked fine.
Cannot do that until the “mouse down in window which has active updates (like counters)” bug is fixed.
It was introduced in 3.22 so I am still running 3.21. The bug is described and confirmed in all the Winbox release topics since 3.22 but nothing is being done about it.
Sure not everyone seems to have this problem, otherwise we’d all be screaming right? Just saying take precautions, because for some installations, this isn’t just “some update”. It might actually blow up in your face. I think that’s valuable info on anything resembling a stable branch.
My config isn’t even that strange I would say. That said, the problem will probably depend on something in the config, otherwise everyone would get it. I’m thinking it’s some sort of legacy thing in there not being “translated” right between updates. The router is now several years old and has seen a considerable number of config changes on many different versions. I also sometimes changed between stable and long-term, which might have something to do with it as well.
That is just standard practice for any update, be it to a stable version or not, of an important device (especially when it is difficult to access).
I always use partitioning and copy the current version just before upgrade so I can immediately go back when disaster occurs.
And yes, it has happened that it booted the new version, paniced, and auto-switched to the alternate partition.
Still, it does not seem that many users use (or even know about) that precaution…
Wine version: wine-4.0 (Debian 4.0-2) (running on Debian 10, updated to latest version)
Same issue on another system running Debian 9 and Wine version wine-1.8.7 (Debian 1.8.7-2)
Cha0s confirmed he has the same issue in Windows 10: Winbox v3.24 released! and on Windows 7 (2 articles above that one).
To reproduce: open a window which has continuous updates, e.g. the IP->Firewall->Filters window on a router which is passing traffic (counters are updating)
Then hold down mouse to either change a column width or to move a rule. At the next update, the mouse pointer will jump and the column gets a wrong width or the rule is moved to an unwanted position.
It looks like you are inn to some. Here is memory usage on MT 6.47 (running on a vmware)
This router only do DoH and used for testing only.
A reboot was done 5 July
My RB750Gv3 that is much more loaded, does not show this behaviour. 6.45.9
