Remote access should not have single point of failure
Remote access to intranets and other restricted areas has always been a trade-off between convenience, security, and reliability. The same applies to monitoring: if network devices should be monitored remotely, the remote-access path itself must not become a single point of failure.
Below are several practical approaches. In many environments, it makes sense to combine more than one of them, depending on how reliable and secure external access to the network needs to be.
Backup ISP connections
If several ISPs are available, it may be practical to use at least two separate ISP lines to access Internet. However, one needs to be sure the lines are actually working.
The checks would require an additional setup on some of internal devices: a number of external devices should try connecting to known external IP addresses (PING, TCP or similar simple means would do); internally, these attempts should be registered; in case there were no oncoming “who’s there” connections, the line may be considered offline.
IPNetwork can check the mentioned “is alive” flag and raise alarm when necessary. Note that IPNetwork Monitor can do more than notify: current alerting actions include running a local script or program, running a command via SSH, setting an SNMP value, or sending an HTTP(S) request. That makes it realistic to trigger a failover workflow when the primary line stops responding to external probes.
Using VPNs
VPNs remain one of the standard ways to reach closed networks securely. OpenVPN is still actively maintained for business remote access, and WireGuard remains a modern lightweight VPN option. Communication is encrypted end-to-end, which is why VPNs are a practical way to protect monitoring traffic over untrusted networks.
Similarly, IPNetwork Monitor can monitor hosts reachable over a VPN to confirm that the path is still usable. It is true that a VPN can reduce the exposure of legacy protocols, but it is better to describe that as a temporary mitigation than as a substitute for upgrading insecure protocols where possible.
Using WiFi or mobile networks
If there’s an external WiFi access points, AP (the one not using the same ISP line(s) used by the intranet), it could also serve as a backup communication line. One should note, however, that WiFi connections can be hard to secure; if multiple WiFi APs are in use in the same area, connection quality can significantly deteriorate.
The same can be said about mobile and satellite networks. While they may not be ideal as a primary monitoring path, they can still be useful as an out-of-band backup route or as a way to preserve alert delivery when the main Internet line is unavailable.
Using GSM modems
GSM modems are no longer the first choice in many environments, but they are still a valid out-of-band backup notification channel. Current IPNetwork Monitor documentation supports configuring both a primary and a secondary GSM modem, automatic failover between them, and sending a test SMS to verify the setup. That makes GSM useful precisely in the scenario this article discusses: when the main Internet path is unavailable but an emergency alert still needs to get through.
Mail delivery should not have a single point of failure
All services responsible for notifications, especially mail delivery, should also be redundant. Current IPNetwork Monitor versions support both a Primary mail server (SMTP) and an Alternate mail server (SMTP); if the alternate server is configured, it is used automatically when the primary one fails to send a message. The product also provides Send test email alert with a recorded SMTP conversation log, which makes failover and delivery problems much easier to verify in advance.
In distributed environments, Remote Network Agents are also worth mentioning here, because they reduce the need to expose every monitored subnet directly and can still be managed from the central installation. Linux support for Remote Network Agent is now part of your current product direction as well.
Conclusion
Have we missed any means to ensure IPNetwork can both communicate and notify, when something goes wrong? If we have, please let us know of your experience – contact us.