10.7.3

Ecessa Firmware Release Notes 
Version: 10.7.3 
Release Date: 2018.02.12 
Revision 1.0: 2018.02.12 

Improvements
1. Added remote endpoint testing options for active IPSec VPN monitoring in the CLI and web interface. 
2. VPN Monitoring is now more efficient in monitoring security associations. 
3. Implement DNS resolver cache system for resolving FQDN's. 
4. Add an option which allows static route sessions to not be disrupted during configuration activation. 
5. Add the ability to push a system snapshot to Ecessa using the web interface. 
6. Diagnostics iperf now has the ability to set UDP bandwidth. 
7. The web interface now informs the user that user account information is not sent to the idle hardware failover device during replication. 
8. Ecessa Insight passive monitoring configuration is now available via the CLI. 

Fixes
1. Loading a configuration with different WAN names could result in a failure to load. 
2. The idle hardware failover unit can get in a state where it can't communicate with the active unit. 
3. Failover type static routes may not have behaved as expected after activating changes or loading a configuration. 
4. QoS applied to WAN Virtualization sites may cause packet loss when packet throughput rates are high. 
5. The GUI "IP Address or Hostname" field for simple host records in a DNS domain will handle only up to 63 characters. 
6. DNS simple host records do not accept underscores where an FQDN is accepted. 
7. Deleting a WAN for an On Demand type VPN can cause the VPN to not come up. 
8. SIP Proxy registrations can become unbalanced across WAN's. 
9. Old IPSec VPN VTI devices may not get removed, possibly preventing successful re-connection. 
10. Devices connected to Ecessa Insight can create duplicate monitoring alerts. 
11. Multiple registrations for the same SIP user from different locations should use different public SIP ports. 
12. Encrypted small packets received over WAN Virtualization can become reordered. 
13. There is no way to display and stop diagnostics iperf servers via the CLI. 
14. DNS zone information may not be properly updated after a WAN status change. 
15. Use DNS resolver cache for aliases containing FQDN's to prevent long delays trying to resolve when the name servers are not accessible. 
16. IPSec L2TP clients may not be able to re-connect if they have a different IP address than the last time they connected. 
17. IPSec VPN Failback option does not work as expected. 
18. Fully qualified domain name used in an alias will get overwritten with resolved IPs. 

Known Issues 
1. When a device is running a configuration which has WAN Virtualization sites and loads a configuration which does not have WAN Virtualization sites configured the device software may restart. 
2. Virtual Product may boot slowly. 
3. Adding an encrypted WAN Virtualization site using the CLI may not work as expected. 
4. The DHCP service can stop unexpectedly. 
5. The LCD display can become stuck and not display new information when keys are pressed. 
6. Enabling WAN Virtualization encryption using the CLI without specifying a VPN name will create an IPSec VPN entry with no name. 
7. Phone calls made within a short time after enabling the VoIP feature may not choose the Primary WAN. 
8. Using the CLI to create an alias with multiple addresses will reorder the addresses and remove duplicates, making the alias unusable for firewall forwarding rules. 
9. When a DHCP WAN is given a very short lease time by the modem the Ecessa device can become unresponsive. 
10. Using Hardware Failover with high traffic throughput can cause excessive loading of the device. 
11. DNS Reverse Zone may not work correctly for load-balanced hosts. 
12. WAN Virtualization which is using non base IP addresses can not route as expected when a static route is in place which applies to all traffic. 
13. WAN Virtualization hub location cannot have a site number that is greater than 127. 
14. Ports can become disabled on legacy 600 product (7568c) when pulling a cable during traffic flow. 
15. Failback static route over WAN Virtualization doesn't fail back after failing over to a WAN.