That is just half of the truth. If RouterOS itself downloads packages that same RouterOS is actually the client.RouterOS is not in any way involved in encrypted (https) connections made by clients. So "certificate pinning" makes no sense.
But it downloads them using http. Not https. So that doesn't matter.That is just half of the truth. If RouterOS itself downloads packages that same RouterOS is actually the client.RouterOS is not in any way involved in encrypted (https) connections made by clients. So "certificate pinning" makes no sense.
If the signing key gets compromised that does not mean access to the original servers.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.
I would not agree with that. The signing keys can be in an airgapped HSM, the servers have to be on the internet.If the signing key gets compromised that does not mean access to the original servers.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.
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.
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...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.
Doesn't seem to work. After upgrading the firmware the lte interface entered an invalid state and I couldn't disable/enabled it.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;
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?Doesn't seem to work. After upgrading the firmware the lte interface entered an invalid state and I couldn't disable/enabled it.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;
Restarting the whole device, restored connectivity.
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.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?
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.
Downgrade then upgrade againI 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.
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?
/ip firewall filter
add action=accept chain=input dst-address-type=!local in-interface-list=WAN log=yes log-prefix="wan non-local"
Could you please elaborate on what misunderstanding you can see?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)
/ip firewall filter
add action=accept chain=input dst-address-type=local in-interface-list=WAN log=yes log-prefix="wan local"
I think you should use the VRF interface as the input interface.I have an issue with VRF & firewall rules in v7.15: src/dst-address-type=!local matches local addresses.
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.Still it seems better to match for multicast or broadcast when that is what you are after, instead of !local.
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.I think you should use the VRF interface as the input interface.
https://help.mikrotik.com/docs/pages/vi ... infirewall
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.
1.1.1.x IP adresses sometimes get blocked by some ISP etc...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...
Thanks for solving this, which I am pretty confident was the root cause for my systems Wifi issues.What's new in 7.15rc5 (2024-May-28 09:53):
*) wifi - improved interface initialization reliability on DFS channels;
Could this help with intermittent lockups when using DFS channels?*) wifi - improved interface initialization reliability on DFS channels;
Yes.Could this help with intermittent lockups when using DFS channels?
*) route - improved system stability
MT Can u explain detail exactly
Thx
+100 !!!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!