The correct answer is to create a loopback interface. When nothing is plugged into the LAN bgroup, the interface goes "down", and all routes associated with it are removed from the routing table. That's a behavior you want, actually, as it helps when using route-based redundant VPNs - it's the only way for a device to know "that tunnel is down and I should now route to over here".
Okay, so what you do is:
- In your vrouter - likely the trust-vr - check the option to "Ignore Subnet Conflict for Interfaces in This VRouter"
- Create a new loopback.1 interface
- Give it the last address in your LAN bgroup space, with a /32 netmask. E.g., if your LAN bgroup has 192.168.1.0/24, loopback.1 would be 192.168.1.254/32. Analogous for smaller net spaces.
- Make sure your DHCP server on that bgroup does not include the loopback interface's address in its IP pool(s).
Now you can manage the unit using that loopback IP address, which will always remain reachable; and you did not have to carve out additional address space to do that.
Ensuring that a tunnel remains "up" is an entirely different concern. In ScreenOS, this can be accomplished with the "monitor rekey" option (and "optimized" for good measure if you want to, with a specific destination IP and source port if the outside isn't pingable, and possibly with an interval of 5 instead of 1 if the lines you go over are residential ISPs). That has nothing to do with being able to manage, however. It can give you good indication and advance warning of VPN failure, if you configure a server that receives logs and sends out notifications to staff on "VPN Down".
It also has the risk of making your VPNs "flap" if you misconfigure - that is, if the address that Monitor is pinging cannot, actually, be pinged, or if the interval is too aggressive for the quality / latency of your ISP connection(s). That can be handled by, for example, pinging said loopback address through the tunnel: You won't be relying on the external address being reachable to ping.