v7.15rc [testing] is released!

Cha0s · Sun May 19, 2024 6:08 pm

When the secret signing key gets compromised in the way Kaldek suggests, it is not an issue if you have a hosts file with bad entries, because the adversary could just put their compromised code on the original servers.

If the signing key gets compromised that does not mean access to the original servers.
It's easier for the key to get leaked, rather than get access to remote servers that may not even be accessible from unknown networks etc, or you may get noticed by monitoring systems, etc.

phin · Sun May 19, 2024 6:31 pm

Adlist seems to work just fine on my 5009, using stevenblacks as a test with 32MB cache. Does not seem to work on my hapac2's.

Can confirm does not work with doh

pe1chl · Sun May 19, 2024 11:07 pm

When the secret signing key gets compromised in the way Kaldek suggests, it is not an issue if you have a hosts file with bad entries, because the adversary could just put their compromised code on the original servers.
If the signing key gets compromised that does not mean access to the original servers.
It's easier for the key to get leaked, rather than get access to remote servers that may not even be accessible from unknown networks etc, or you may get noticed by monitoring systems, etc.

I would not agree with that. The signing keys can be in an airgapped HSM, the servers have to be on the internet.

Kaldek · Mon May 20, 2024 7:07 am

Folks I get the defense of Mikrotik here and the discussion around certificates. The work still has to be done; whomever is responsible for developing the adlist functionality should always assume the worst, and design to that.

pe1chl · Mon May 20, 2024 12:06 pm

When you configure such a service and pull data from an external provider, you should always realize what may happen when they send you bad data. Even when the router ignores the actual address in the lists (which I think it does...), there still is the risk that this external service is blocking sites that are of essential value to you. Any type of blocking, whether it be ads, malware, sites with content you do not want to see, or whatever, can always lead to unintended effects.
When using bulk lists retrieved from someone else, the more so. When you do not like that, just don't touch adlist (or the other mechanisms proposed here to load lists).
I still think redirecting updates is not a relevant risk. Updates are signed and manipulated updates are not installed.
The source does not matter, at this time you can already setup an updates mirror site and have your routers load the (valid) updates from there.

bratislav · Mon May 20, 2024 12:22 pm

ROS does no HPKP as far as I know. It's something a client should do. As for any connections made by ROS itself: ROS does not ship with certificate bundles. You need to import the ones you trust anyways. So it does not get more secure.

HPKP is obsoleted and deprecated for years and removed from most browsers, on the other hand Mikrotik did not publish exactly how RouterOS validates packages as far as I know but I am certain that some kind of signature validation is in place and package validation most likely uses private certificates store that just isn't exposed...

infabo · Mon May 20, 2024 1:45 pm

Then CT - whatever. ROS does not trust any certificate by default, because it does not ship CA bundles. And their ROS packages are pretty sure signed with their own keys anyways. This discussion is obsolete.

dav26 · Mon May 20, 2024 3:28 pm

Still have problem with different VRFs and IPSec over GRE (or basically GRE Tunnel with IPSec secret enabled).

Does anyone had same issue? Already opened a support ticket but didn't received reply for almost 1 month

Tue May 21, 2024 10:03 am

What's new in 7.15rc4 (2024-May-20 14:43):

*) lte - fixed situation where link is not restored after Quectel MBIM modem firmware update;

Rox169 · Tue May 21, 2024 2:49 pm

seems that stable is around corner :)

Cha0s · Tue May 21, 2024 7:11 pm

What's new in 7.15rc4 (2024-May-20 14:43):

*) lte - fixed situation where link is not restored after Quectel MBIM modem firmware update;

Doesn't seem to work. After upgrading the firmware the lte interface entered an invalid state and I couldn't disable/enabled it.
Restarting the whole device, restored connectivity.

Znevna · Tue May 21, 2024 11:28 pm

So .. I had two partitions on a CCR2116-12G-4S+ running 7.14beta4 (both partitions with the same version and config), I've tried to update to 7.15rc3, the log on the first boot after update was telling that the update went fine but .. it booted into 7.14beta4, and the 2nd partition was.. empty. I've updated again, this time it booted into 7.15rc3, I've made a copy again on the 2nd partition... will it go away on the next update again? meh.

leonardogyn · Wed May 22, 2024 2:53 am

Small cosmetic bug, which I can reproduce all the times. On the very FIRST login right after a reboot, with v7.15rc4 (and noticed from previous RCs from 7.15 as well), the webfig skin is NOT applied, despite configured. Logout, login again, and the skin is now applied. I can reproduce it as many times I want. Just reboot, login, no skin applied. Logout, login, skin applied.
.
very FIRST login right after reboot

v7.15rc4-1st-login.png

.
.
any other login except the very 1st after the reboot

v7.15rc4-2nd-login.png

Wed May 22, 2024 9:19 am

What's new in 7.15rc4 (2024-May-20 14:43):

*) lte - fixed situation where link is not restored after Quectel MBIM modem firmware update;
Doesn't seem to work. After upgrading the firmware the lte interface entered an invalid state and I couldn't disable/enabled it.
Restarting the whole device, restored connectivity.

This sounds like something else than what this exact commit fixed, in this situation, you would be able to restore the link with disable/enable. Do you by any chance have a supout generated while the device was in this state? Could you create a new support ticket with it?

Cha0s · Wed May 22, 2024 11:10 am

Doesn't seem to work. After upgrading the firmware the lte interface entered an invalid state and I couldn't disable/enabled it.
Restarting the whole device, restored connectivity.
This sounds like something else than what this exact commit fixed, in this situation, you would be able to restore the link with disable/enable. Do you by any chance have a supout generated while the device was in this state? Could you create a new support ticket with it?

I don't have a supout from the time that it was in an invalid state. I guess sending one now that I restarted the device and the lte interface came up, won't help you much.

JJT211 · Wed May 22, 2024 11:37 am

This sounds like something else than what this exact commit fixed, in this situation, you would be able to restore the link with disable/enable. Do you by any chance have a supout generated while the device was in this state? Could you create a new support ticket with it?
I don't have a supout from the time that it was in an invalid state. I guess sending one now that I restarted the device and the lte interface came up, won't help you much.

Downgrade then upgrade again

vovan700i · Wed May 22, 2024 4:21 pm

Hi,

I have an issue with VRF & firewall rules in v7.15: src/dst-address-type=!local matches local addresses.

Suppose you have a few WAN interfaces, one of them assigned to a separate VRF, and you would like to filter packets based on whether they have a local address as destination or not. Then the following rule matches all incoming packets with a non-local destination:

/ip firewall filter 
add action=accept chain=input dst-address-type=!local in-interface-list=WAN log=yes log-prefix="wan non-local"

It works well for all WAN interfaces assigned to main VRF. For the WAN interfaces assigned to a separate VRF, this rule is triggered for both local and non-local destination addresses, i.e. v7.15 firewall treats any destination addresses of all packets incoming to non-main-VRF interfaces as non-local (because an automatically created VRF interface has no address?) and doesn’t take into account the addresses assigned to such interfaces.

Suppose it happens due to the changes made in v7.15 with regards to VRF interface matching in firewall as described by the official manual here.

Reported it to the support 5 days ago (SUP-153295). No answer yet, though it seems to have some undesired security implications (e.g. if you intend to drop non-local traffic, it will also drop local traffic).

Can anybody else confirm this wrong firewall behaviour with VRFs?

Regards,

pe1chl · Wed May 22, 2024 4:31 pm

Actually this example of a firewall rule seems to point out a basic misunderstanding of what the "input" chain is...
(and maybe as well of what "local" addresses are)

vovan700i · Wed May 22, 2024 5:26 pm

Actually this example of a firewall rule seems to point out a basic misunderstanding of what the "input" chain is...
(and maybe as well of what "local" addresses are)

Could you please elaborate on what misunderstanding you can see?

My understanding is dst-address-type=local should match all packets where destination is set to one of the addresses assigned to all local interfaces (or included into a list, as in my example). It perfectly matches the official docs.

Conversely, dst-address-type=!local should match any packets where destination has any IP other than the assigned addresses. E.g. broadcast/multicast addresses.

I can also put the issue in another way: the following code doesn't match locally destined traffic on v7.15 VRFs

/ip firewall filter 
add action=accept chain=input dst-address-type=local in-interface-list=WAN log=yes log-prefix="wan local"

pe1chl · Wed May 22, 2024 5:57 pm

Lots of people seem to think that address type "local" means an address on the local network(s). Apparently not you.
Also, some people think that traffic being forwarded also passes through the input chain. But that isn't the case.
Still it seems better to match for multicast or broadcast when that is what you are after, instead of !local.
I cannot help you with VRF issues, I have always stayed away from it because for my purposes it has too many bugs and limitations.

clambert · Wed May 22, 2024 6:42 pm

I have an issue with VRF & firewall rules in v7.15: src/dst-address-type=!local matches local addresses.

I think you should use the VRF interface as the input interface.
https://help.mikrotik.com/docs/pages/vi ... infirewall

vovan700i · Wed May 22, 2024 7:17 pm

Still it seems better to match for multicast or broadcast when that is what you are after, instead of !local.

I tend to agree, however if packets with dst-address-type=local are matched by dst-address-type=!local rule, then dst-address-type=local rule matches no packets at all, and I can't drop tcp/22 on VRFs, for example. Actually, I can use other rules to do that, but it's out of the scope of the issue we're discussing.

I think you should use the VRF interface as the input interface.
https://help.mikrotik.com/docs/pages/vi ... infirewall

Good catch, already tried to a) add the VRF interface to the wan list, b) replace the wan list with the VRF interface. The problem persists.

lilianmoraru · Fri May 24, 2024 5:48 pm

Moved from 7.15rc2 to 7.15rc4 and after a few days, DNS completely stopped working.
- Tried flushing DNS(Mikrotik Cache) - did not help.
- Removed my local DNS(PiHole + unbound) and switched to 1.1.1.1 + 1.1.1.2 - did not help.
- Restarted a bunch of times and tried to set ISP IP as DNS - did not help.
- Added a third DNS server: 1.1.1.1 + 1.1.1.2 + 8.8.8.8 and suddenly it started working - first thing I did is revert back 7.14.

I have a feeling that 7.15rc3(maybe the DNS Adlists in general) might of introduced a regression with DNS but I have work to do and didn't go into a deep dive...

infabo · Fri May 24, 2024 6:01 pm

It stopped working after a few days and reboot "a bunch of times" did not - at least temporarily - resolve the issue sounds more like an issue elsewhere.

daaf · Sat May 25, 2024 4:40 am

daaf - Can you please provide supout files from your access points to support@mikrotik.com? Please make sure that files are generated at the moment when APs are not working properly.

Under support ticket SUP-153071 they sent me version 7.16 and the problem persists, after debugging I was able to replicate the problem, the access lists do not work properly. The devices are rejected.

massinia · Sat May 25, 2024 8:02 pm

The contents shared with DLNA (IP>Media) are displayed on all devices (smartTV, smartphone, etc, etc) in random order and not in alphabetical order.
In some cases the order Z -> A is followed instead of A -> Z

For more details SUP-154088

nichky · Sun May 26, 2024 2:23 pm

When redistribute def-route via VRF will be added (on v6 that works perfectly fine).

I've been advised from the support teams that this is still not implemented on v7, but do we know what that will be?

Tue May 28, 2024 3:27 pm

What's new in 7.15rc5 (2024-May-28 09:53):

*) lte - improved FG621-EA modem APN authentication;
*) route - improved system stability;
*) webfig - fixed issue where skin is not applied on first login after reboot (introduced in v7.15beta8);
*) wifi - improved interface initialization reliability on DFS channels;

bratislav · Tue May 28, 2024 4:20 pm

Moved from 7.15rc2 to 7.15rc4 and after a few days, DNS completely stopped working.
- Tried flushing DNS(Mikrotik Cache) - did not help.
- Removed my local DNS(PiHole + unbound) and switched to 1.1.1.1 + 1.1.1.2 - did not help.
- Restarted a bunch of times and tried to set ISP IP as DNS - did not help.
- Added a third DNS server: 1.1.1.1 + 1.1.1.2 + 8.8.8.8 and suddenly it started working - first thing I did is revert back 7.14.

I have a feeling that 7.15rc3(maybe the DNS Adlists in general) might of introduced a regression with DNS but I have work to do and didn't go into a deep dive...

1.1.1.x IP adresses sometimes get blocked by some ISP etc...
Are you sure PiHole + unbound are not using 1.1.1.1 as forwarders too?
Are you sure your ISP is not using 1.1.1.1 as forwarders too?
Maybe only the 8.8.8.8 (Google) is working now... Maybe try 1.0.0.1 (Cloudflare alternative DNS server IP address) and see if it is working.
Why revert back now when DNS is working?

Anyways from what you are saying it may not be RouterOS at all...

WeWiNet · Tue May 28, 2024 7:07 pm

What's new in 7.15rc5 (2024-May-28 09:53):

*) wifi - improved interface initialization reliability on DFS channels;

Thanks for solving this, which I am pretty confident was the root cause for my systems Wifi issues.

Edified · Tue May 28, 2024 10:24 pm

In WinBox WireGuard Peer under Client Settings we need a field for AllowedIPs

This is so that the Client QR can be configured to only route traffic for particular IPs to via the tunnel, instead of making it the default route (0.0.0.0/0).

Right now I have endpoints scan the code, but then have to manually change the AllowedIPs per device, which is an unnecessary job.
Thanks!

DjM · Tue May 28, 2024 11:08 pm

Hello MikroTik team,

Any chance to get the REST API user logout issue solved within this upcoming version? - topic is discussed viewtopic.php?t=207040 , unfortunatelly there was no reply with SUP ticket ID.

Thank you

buset1974 · Wed May 29, 2024 5:29 am

*) route - improved system stability

MT Can u explain detail exactly

Thx

Smoerrebroed · Wed May 29, 2024 12:05 pm

*) wifi - improved interface initialization reliability on DFS channels;

Could this help with intermittent lockups when using DFS channels?

Wed May 29, 2024 12:28 pm

Could this help with intermittent lockups when using DFS channels?

Yes.

infabo · Wed May 29, 2024 1:13 pm

I hope 7.15 is going to fix most of DFS channel re-select issues reported here on the forum.

Thu May 30, 2024 7:27 am

In simple words - we discovered that RouterOS internally did some unnecessary checks on specific situations under the hood, so we improved some part of code making routing processes more agile. You should notice the difference on large routing setups, not on a home router.

*) route - improved system stability

MT Can u explain detail exactly

Thx

lluu131 · Thu May 30, 2024 9:54 am

Very good, everything works fine after the update, looking forward to the official version!

Njumaen · Thu May 30, 2024 10:32 am

In WinBox WireGuard Peer under Client Settings we need a field for AllowedIPs

This is so that the Client QR can be configured to only route traffic for particular IPs to via the tunnel, instead of making it the default route (0.0.0.0/0).

Right now I have endpoints scan the code, but then have to manually change the AllowedIPs per device, which is an unnecessary job.
Thanks!

+100 !!!

This is very important and should not be too hard to implement! Please!

Santi70 · Thu May 30, 2024 11:53 am

Being in the latest version rc5 I have realized that when roaming I get a positive signal intensity, is this normal? I use an ax3 as a capsman and an ax2 as an AP

pos.png

Thu May 30, 2024 12:02 pm

RouterOS v7.15 has been released
viewtopic.php?t=208039