Release Notes

1. Introduction

This document provides information on the features, improvements, and known issues for this Secure Edge release.

Product naming updates

To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

2. Changes in this Release

2.1. New Features

• WAN High-Availability: Allows for the use of a secondary port for the iNode’s WAN connection, allowing for more resilient installations.

• MAC Address Pinning: The iNode MAC addresses are now fixed for Networks and Services. This will better support networks that require MAC address allowlisting. We’ve also added a MAC Address overview tab on the iNode Details page.

• Representation Networking Table: We’ve added a table that lists all of the RepNets that are in-effect within Secure Edge. It also includes a handy calculator tool to help you with your NAT translation.

• Unified Cloud Gateway: We’ve introduced a cloud based proxy solution that reduces the number of allowlist entries on your firewall required for the iNode’s outbound connections.

• Static Routing on the Virtual iNode: You can now create static routes within the Virtual iNode network configuration. This enhances your ability to integrate with cloud based systems behind the Virtual iNode.

2.2. Enhancements

• iNode Management Enhancements: An Admin can now move Unassigned iNode Serial Numbers between their child organizations.

• Services Enhancements: Services can now be mounted to multiple networks. You can select which networks to mount to from the Service creation workflow.

• Networking Enhancements: The iNode now supports onboarding southbound networks with the same CIDR (or subnet) configuration. RepNet can be applied to these duplicated networks to avoid conflicts.

• Child Org Management Enhancements: We’ve removed the requirement to add a billing contact when creating child orgs.

• Other Enhancements:

  • We’ve included two vulnerability fixes. One is for the Docker CVE-2024-21626 that we previously notified you about. Second was related to our continuous pen-testing efforts.

  • We’ve made enhancements to the View Remote Access Agent to increase its stability.

2.3 Bug Fixes

• We fixed a bug where the parent org dashboard may not show the Continuous Threat Intelligence threats detected in child org

  3. Prerequisites

  3.1. Cloud Requirements

  The following cloud platforms are supported:

  • Amazon AWS

  • Microsoft Azure

  • VMware vSphere v6.x

  • Google Cloud

  3.1.1. Virtual iNode Compute Requirements

  2 vCPU, 2GB RAM, 10GB HDD, Public IP address

  4. Issues

  4.1. Limitations

  1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status to be updated to Alive in the Secure Edge Portal.

  2. When connecting iNodes from the Secure Edge Portal the first time, both iNodes should be in the Alive status.

  3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.

  4. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.

  5. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.

  6. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.

  7. Volume created for SkySpark license is required to have a filename with extension ".props".

  8. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.

  9. When Standalone Mode is activated for an iNode from the Secure Edge Portal, the iNode needs to be ALIVE for at least one minute for the change to take effect.

  10. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.

  11. The maxium size of the downloaded Service logs is limited to 10 MB.

  12. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.

  13. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.

  14. Editing a Secret requires the Service to be restarted to take effect.

  15. Service addressing can be set only when adding the network and can not be changed later by editing the network.

  16. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.

  17. In the hardware monitoring, the Power supply status and its temperature is not reported.

  18. When configuring timezone settings for the container, application container packager has to ensure that "tzdata" and "date" packages are installed in the container image to take effect.

  19. When configuring timezone settings for the container, please add the label "_iotium_core_service=true" to the Core services to ensure they aren't affected by container time zone setting. Services without "_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.

  20. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page in the Secure Edge Portal is that of the proxy IP.

  21. Firewall rules cannot be applied for the Inter Traffic Routing within edge iNode.

  22. One-Arm mode is not supported with Multi NIC

  23. Intense scan report shows offline hosts also.

  24. Scan status is updated after 3 mins.

  25. TAN Routing  is not supported for dynamic TAN

  4.2. Known Problems

  1. If no service log has been generated in the last 24 hours, the Service Logs window in the Secure Edge Portal will not show any logs even if there are logs generated earlier.

  2. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.

  3. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.

  4. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.

  5. Metrics graph does not show any break, if iNode loses management connectivity for a moment.

  6. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.

  7. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.

  8. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.

  9. Static routes to allow remote networks will not work if static routes with Representational Network is configured.

  10. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.

  11. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.

  12. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don't synchronize time with the NTP service.

  13. The list of configured time servers and the server iNode is currently synchronized to is not available in the Secure Edge Portal for iNodes with debian distro.

  14. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Secure Edge Portal.

  15. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.

  16. iNode conversion to cluster is not supported if dynamic addressing mode TAN networks exists in iNode.

  17. Threat Intelligence enable/disable is not logged in activity log.

  18. Parent org dashboard may not show the threats detected in child org.

  19. Bulk User create/edit will be performed in the organization of the logged in user.

  20. Threat detected in child org is not consolidated in parent org's dashboard.

  21. Device Discovery enable/disable is not audited.

  22. iNode’s location will be plotted randomly when an invalid address is entered.

  23. Device Discover is not supported in cluster

  24. Scan report of a scan config will be deleted when the scan config is deleted.

  25. Bacnet information is not available in downloaded report.

  26. Device discovery config is not allowed for 10 mins from TAN network edit.

  27. SSO org login or page navigation will throw error sometimes, need page refresh to load the page.

  28. Console connection to Edge iNode will not work via an interface, when multinic is enabled and TAN network is created for that Interface.

  5. Archives

  To view Release Notes for earlier versions, see here.