Currently, REDs and ASG must find and connect through the definition of a single host-name that is fully resolvable in the public. While this can use the DynDNS feature in ASG already for "fail over", it might be more simpler to just offer another host-name field to be used in the event RED looses connection to the main host-name?

Even with multiple WAN links avaialable to an ASG, the REDs use of just a single hostname poses a problem if that particular WAN link or ISP should drop for a time (e.g. fiber cut, dead modem, etc). The downed REDs wouldn't be able to connect in such a situation without some significant workarounds (e.g. DNS records modified to work with the other IPs and associated adjustment in TTL settings, ISP setting to redirect traffic, reconfiguring the host name on the ASG and on the corresponding REDs, etc.)

A backup secondary IP or hostname would be a nice enhancement that would help strengthen what appears to be a weak link in scenarios where remote office RED(s) rely on just a single ASG at the home office for internet access.

Such flexibility might also provide more flexibility to the ASG's automatic up-link balancing features as up-link balancing would likely already be configured and in use with multiple WANs present.

RED's current fail-over internet access not much help. RED needs a fail-over internet access option for if the ASG becomes unavailable.

Proposed functionality:
If ASG becomes unavailable due to ASG side failure, Red should maintain it's config (LAN side IP, Wan IP ) and simply switch to split tunnel mode allowing internet traffic to flow out on the local internet uplink and tunnel traffic to just drop since the tunnel is down. When link to ASG is re-established it would switch back to unified routing mode. Internet uptime is critical, so we can live with RED splitting the internet bound traffic out on the local WAN in the event of downtime at headquarters where ASG is located. I know with high-availability and multiple WAN links at ASG site downtime may be rare, but a safety net would really make sense.

The current fail over option in RED is really odd... and I'm not sure how it could be useful.

The initial configuration for RED10 devices has no protection against a stolen RED10 device being used to connect back to internal systems.

There needs to be an option to lock the RED10 device to an IP or hostname so that a connection won't be accepted unless it comes from the authorised location.

For static IP's locking to an IP is fine

For Dynamic IP's:

Instead of locking to an IP it could be locked to a DNS host name. When a connection attempt is made the ASG hub could perform a Reverse DNS lookup. If the returned hostname for that IP matches the configured hostname then the connection would be allowed.

This would mean Dyn-DNS could be used for locations with a dynamic IP.

Reverse DNS lookups would need to use results from the authoritive DNS server and not cached or non-authoritive results. This would prevent false rejections after an IP change and also protect against DNS cache poisoning.

The option to lock a RED10 device to an IP or Hostname MUST be optional as many people want to use it as a roaming office device.