Updated the existing ROS 7.9 to 7.11.2 and can confirm that the initial issue is fixed.
Thank you, devs.

Can't say about the Proton certs. I mean the initial problem this topic is about.

ROS 7.10 release is also still affected by this issue.

What is the version of ROS ? It looks as if the functionality is broken in ROS 7.9 (most possible). At least, IPsec with certificate-based authentication doesn't work as expected in 7.9 because of "*) ipsec - refactor X.509 implementation;". At the moment, there are no confirmations/rebutt...

Thank you folks for your advises. Fortunately, the affected ROS instance was CHR, I restored it from backup. I set up a separate CHR instance with ROS 7.9 configured it from scratch and re-tested the issue. So yes, the described behavior was reproduced. IPsec between ROS 6.49.[6,7] and ROS 7.9 with ...

Hi, community and Mikrotik staff. There is a defect in 7.9 related to certificates. Most possibly due to the "*) ipsec - refactor X.509 implementation;" In my setup, I have ROS 7.8 connected to ROS 6.49.6 via IKE2: auth: digital signature My Type ID: auto remote type ID: auto Match by: rem...

Hi, Community and Mikrotik experts. Does ROS 7.7 process CRLs correctly? In my setup, I have two Mikrotik routers, one on 6.49 and another on 7.7. Both are configured to get certificate CRLs from the same Microsoft AD Root CA. The CA publishes one base CRL and one differential CRL. The 6.49 download...

are there drivers on the way for VMware and Hyper-V/Windows? Not planned at the moment. No Windows/HYPER-V native support. Possible, the 3 of 4 PCIe emulated NICs can be passed to a HYPER-V VM (Linux/FreBSD) via DDA but SR-IOV is required for that. Otherwise - no way at the moment. Though, it shoul...

BTW. It may be possible to use the device on Windows with HYPER-V and DDA. If you have a modern motherboard that supports SR-IOV, it is possible to dismount the AR8151 devices #2..#4 and passthrough them to a HYPER-V VM. Linux or FreeBDS inside the VM should work well with the passed devices. Howeve...

Because the CCR2004-1G-2XS-PCIe takes some time to boot ROS, on Linux a rescan for PCI devices has to be initiated.
How is this done on Windows?

Via boot delay. CCR2004-1G-2XS-PCIe is booting up for ~ 11 seconds so a boot delay of 15 seconds is enough.

But why would you want to use one of these with Windows ?

Because Windows has HYPER-V and allows building labs or even production environments with no side virtualization software. It is enough convenient.

Isn't Proxmox based on Linux/KVM? Also, I don't see the Proxmox being used widely in Enterprise.

How the device is represented on PCIe bus? I.e. does the card provide 4 independent PCIe network adapters or one multifunction PCIe network adapter? Does the device require PCIe bifurcation? The first PCIe network adapter looks quite different from 3 other adapters. ESXi 5/6 have VMKLinux stack, so ...

Just secure your CHR instance as you need immediately after deployment.

Actually, yes, because the "disable-ipv6=yes". This configuration disables IPv6 per device so "IPv6 not supported for this device".

Ok, could you, please, folks, explain then, how to configure properly IPv6 PtP connection at the ROS7 (e.g. v7.2.1) with /128 instead of /127 ? Setup 1 based on /127: FD01::/64 - [ (eth2) R1 (eth1) ] - FD05::2 /127 ()--PtP conn--() FD05::3 /127 - [ (eth1) R2 (eth1) ] - FD02::/64 At the R1: IPv6 addr...

2 Sob : /127 in IPv6 is like /31 in IPv4 Definitely, it isn't valid due to the difference between IPv6 and IPv4. IPv6 /127 is like IPv4 /30 (not the /31). The IPv4 /31 provides 2 special addresses (1 network address and 1 broadcast address) and 0 node addresses. This is why IPv4 /31 is senseless, th...

Awful... What are you telling??? Is it actually possible at all? It's just a joke. I'm not an amateur and not a newbie neither in software nor in networks. Even "enterprise-grade" contracts don't scare me. Thank you for the advice. I appreciate it a lot. But it has nothing to do with this ...

I believe DEVs are responsible for buggy features in "stable" releases. In alphas, betas, dev- and test- releases they can do everything they wish - no any complaints about that. But the "stable" means the stable. It is a well-documented and well-tested release. Frankly speaking,...

The problem with the IPv6 NETMAP isn't a big problem. The problem is that the DEVs keep silent. It isn't a big deal to post an update like "Folks, don't rush with the IPv6 NETMAP - it is implemented buggy". Just 1 minute to post such update which could explain the things and avoid all thes...

Actually, this restriction is correct. As the NETMAP changes SRC addresses - the placement chain is correct. it should be placed in DSTNAT chain because these changes should be done in PREROUTING chain-set. The problem is that the IPv6 netmap doesn't perform prefix translation at all. Functionally i...

Do you know that ROS 7.1.1 allows you to put IPv6 NETMAP only in DSTNAT chain? Did you test it? Just test - you will be surprized so much.

The DST-ADDRESS will never work because the fd20::/64 in the example - is source prefix, not destination. I know how it can be done with SRCNAT/DSTNAT. Or SNPT/DNPT for IPv6. Thie question was not "how it can be implemented with SNPT/DNPT". The question was "how to configure IPv6 NETM...

It looks as if you didn't test the IPv6 NETMAP. I mean that DSTNAT forwards traffic to just one destination IP - it changes destination IP. NETMAP must not even touch the destination. It must change the source IP prefix to another specified prefix. It is what NETMAP (1-to-1) should do. It is its log...

I don't think it works as dstnat. It works as dstnat. They are completely different things. I wish to think it works as NETMAP but it doesn't work as NETMAP. I tested it. Did you test how IPv6 NETMAP works? I did. Therefore I wrote that in current implementation the IPv6 NETMAP works the same as DST...

I tested the IPv6 NETMAP feature - it works the same as DSTNAT. It looks as if the feature is broken or just a stub feature... Also, there are SNPT/DNPT actions in mangle chains - they also work pretty oddly... Anyway, with no well-written documentation, we can just guess why these odd features were...

Hi, folks. Could you, please confirm that the IPv6 NETMAP works properly in ROSv7.1.1 CHR? For some reason, I can't get it working. I dig deep into official documentation but there are even no words about the feature. From logs I see that it doesn't work as expected. Microtik guys - could you, pleas...

and if you don't use DoH (because for some strange unexplained reason RouterOS ignores FWD when DoH is used).

Yep, confirming that DNS forwarding doesn't work with DoH enabled.

2 Sob : If no policy exists, it's true for all packets none doesn't match ipsec-policies even if they are defined 2 pe1chl : I checked your example. It works the same with no ipsec-policy=in,none in the second rule: add action=accept chain=input-inet comment=L2TP/IPsec dst-port=1701 \ ipsec-policy=i...

It looks as if the IPsec-policy matcher in 6.47 is broken: ipsec-policy=in,none matches all incoming packets even if no any ipsec policies are defined. Repro-case: /ip firewall filter add chain=input ipsec-policy=in,none action=log log-prefix="ipsec-policy matched test" make this rule firs...