Technical Tip: The routing table update attempted by the link monitor does not work for dial-up IPsec VPN types.

diagnose sys link-monitor status

Link Monitor: LinkVPN, Status: dead, Server num(1), HA state: local(dead), shared(dead)
Flags=0x3 init no_src_route, Create time: Thu Jan 30 16:16:47 2025
Source interface: VPN-A (1438)
Source IP: 192.238.11.78
Interval: 500 ms
Service-detect: disable
Diffservcode: 000000
Class-ID: 0
Peer: 192.238.11.77(192.238.11.77)
Source IP(192.238.11.78)
protocol: ping, state: dead
Packet lost: 100.000%
MOS: 4.350
Number of out-of-sequence packets: 0
Recovery times(0/5) Fail Times(3/5)
Packet sent: 14, received: 0, Sequence(sent/rcvd/exp): 15/0/0

get router info routing-table all | grep VPN

S 192.233.181.0/26 [5/0] is directly connected, VPN-A, [1/0]
S 192.234.181.0/26 [5/0] is directly connected, VPN-A, [1/0]
S 192.235.181.0/26 [5/0] is directly connected, VPN-A, [1/0]
S 192.236.181.0/26 [5/0] is directly connected, VPN-A, [1/0]
S 192.237.181.0/26 [5/0] is directly connected, VPN-A, [1/0]
C 192.238.11.76/30 is directly connected, VPN-A
C 192.238.11.78/32 is directly connected, VPN-A
C 192.239.11.76/30 is directly connected, VPN-B
C 192.239.11.78/32 is directly connected, VPN-B
S 192.240.181.0/26 [5/0] is directly connected, VPN-A, [1/0]

Reason:

This is expected behavior. It will not affect the routing table if the link-monitor is configured on a dial-up tunnel with the net-device disabled(default).

Workaround:

If this dial-up tunnel has only one spoke, it must be set to a static tunnel. If not, it should use the static route with the gateway specified and BFD enabled.

Related article:
Technical Tip: Configuring Bidirectional Forwarding Detection (BFD) for static routes