Could we get more information and examples on this new check gateway feature? What happens if it cannot reach the gateway?
For IPv6, it can take arp as a valid option, what does that mean?
*) dhcpv4/v6-client - added check-gateway parameter;
Check gateway has always been an option on static routes. It verifies that the gateway is reachable, and if not it disables the route.
Now that option is also settable for the default route obtained via DHCP.
As you can also set the “distance” for the default route, and you can add a static default route or obtain it via a routing protocol, at some other “distance” value, this new option allows you to use a DHCP-obtained default route either as a preferred route (with a fallback to some other) or as a fallback for some other preferred route.
When the DHCP client adds default route provided by server, it will add the check-gateway= to the dynamically add /ip/route dst-address=0.0.0.0/0.
So it follows logic in /ip/route docs (IP Routing - RouterOS - MikroTik Documentation):
Gateway check can be extended by setting check-gateway parameter. Gateway reachability can be checked by sending ARP probes, or ICMP messages or by checking active BFD sessions. The router periodically (every 10 seconds) checks the gateway by sending either an ICMP echo request (ping) or an ARP request (arp). If no response from the gateway is received for 10 seconds, the request times out. After two timeouts gateway is considered unreachable. After receiving a reply from the gateway it is considered reachable and the timeout counter is reset.
Previous version you’d have to some machination in scripting and use static routes with the “check-gateway”… so this let you set that WITHOUT a script. Typically check-gateway is used for “multiwan” / failover.
Updated to 7.19, one IPSEC channel is not establishing anymore — “can’t verify peer’s certificate from store”.
UPD: turning off and turning on again “Trust” status on certificates helped to solve this problem.
What is this funny business with the webfig mikrotik_logo.svg?
Upgraded hAP ac2 with wifi-qcom-ac package from 7.18.2 to 7.19. Free space went from 244KiB to 148KiB, ouch. But it least it worked. I was afraid 7.18.2 was the end of the road for it, now it’s really running on fumes.
I have a slightly modified default configuration there. Export file with show-sensitive is 8.35K.
LOL. I’ve noticed that too, I wasn’t sure if it was just rendering… But logo SVG looks like an export, it just a long path. From my Latvian history lessons (https://youtu.be/rgo7pKDb4c8?si=C5lOGmupBHoZGaUL&t=532), it’s not the “hand crafted geometry” I’d expect from Mikrotik. 
What I expect to happen, when used in conjunction, is that they scan for a better channel each time one is triggered.
Channel.reselect-interval — 07:00:00. Scan for a new channel every 7 hours. (If setting is configured at 00:53:00 then the next time it would scan at 07:53:00, 14:53:00, etc.)
Channel.reselect-time — 00:00:00. Scan for a new channel at midnight.
So in my above example if you used both than the channels would be rescanned at
00:00:00,
00:53:00,
07:53:00,
14:53:00,
21:53:00,
00:00:00,
04:53:00,
etc.
Could be wrong, haven’t tested it yet, but logically that’s how I would assume it is supposed to work.
*) bgp - fixed input.accept-community;
at last, no more using input accept NLRI hack again lol
This is not a clock time, but a timer. For example, reselect interval “07:00:00-14:53:00” will select random number between 7h and 14h53m and then will perform reselect. Then again it will generate random timer between these values.
Good for situations when you have many CAPs - in such way you can randomise their channel selection time and avoid situation when all APs use the same channel since they did run a scan at the same time.
Ahh good to know! Thank you for the correction strods! I misread the documentation, for some reason I was thinking that if you only provided one interval that it wouldn’t be random.
E.g. 07:00:00 instead of 01:00:00-07:00:00
My central point was upgraded. After the upgrade it cut all OpenVPN clients (other Mikrotiks) because there seems to be some problem with a certificate. What to do now? Hopefully I don’t need to touch all the clients… the CA cert should be still valid, it is self-signed. I think this was caused by adding the built-in CA feature.
debug: <195.168.229.239>: disconnected <TLS error: ssl: no trusted CA certificate found (6)>
Solution: Guys really watch out, if you are upgrading remotely, this will just cut you off if you are using certificates. Disabling and enabling “Trusted” works, but this seems like a nasty bug. I was lucky my router has 4G backup.
This format is not correct. It needs to be:
1m..3m for between 1 minute and 3 minute interval
1h..3h for between 1 hour and 3 hour interval
e.g.
Hi,
Peer IPSec:
“can’t verify peer’s certificate from store”
[tuPrima@SA0001] > /certificate/settings/print
builtin-trust-anchors: trusted
crl-download: no
crl-use: no
crl-store: ram
[tuPrima@SA0001] > /ip/ipsec/export
# 2025-05-23 02:00:51 by RouterOS 7.19
# model = RB750Gr3
/ip ipsec policy group
add name=group_core01
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
add dh-group=ecp384 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha384 lifetime=1d30m name=pf_pha1_core01 prf-algorithm=sha384
/ip ipsec peer
add address=domain.com disabled=yes exchange-mode=ike2 name="peer=>Core" profile=pf_pha1_core01
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add auth-algorithms=sha256,sha1 lifetime=4h30m name=pp_pha2_core01 pfs-group=ecp384
/ip ipsec identity
add auth-method=digital-signature certificate=IKEv2_MGMT.crt comment=MGMT generate-policy=port-strict peer="peer=>Core" policy-template-group=group_core01
/ip ipsec policy
set 0 disabled=yes
add comment=Gestion dst-address=100.64.0.1/32 level=unique peer="peer=>Core" proposal=pp_pha2_core01 src-address=172.16.30.0/24 tunnel=yes
add dst-address=100.64.0.1/32 level=unique peer="peer=>Core" proposal=pp_pha2_core01 src-address=10.7.0.0/20 tunnel=yes
add dst-address=100.64.0.1/32 level=unique peer="peer=>Core" proposal=pp_pha2_core01 src-address=100.64.90.3/32 tunnel=yes
*) certificate - fixed cloud-dns challenge validation for sn.mynetname.net (CLI only);
Is it my correct assumption that the parameter “type” was removed and it is decided internally whether it uses dns-01 or http-01 challenge?
hap ac2 runs out of disk space, it used to have ~500KB available on the previous version, but now it just went to zero after 2nd reboot (firmware upgrade).
With wifi-qcom-ac package??
hmmm in the mean time I see also a failed upgrade.
I wait some days to see more HAPac2 experiences… (This is my main Wifi AP)
if you netinstall and use the wireless package instead of wifi-qcom-ac you will going to have at least 840k give or take
wifi-qcom-ac
didnt worked for me …
some ipsec peers stil work some not after upgrade from 7.18.2 to 7.19