Authentication OIDC Authentication VNS3 Licensing Access Management Clientpack Generation Installing HTTPS Firewall 2.0 Firewall AWS Specific features Firewall FWSets VNS3 Variables VNS3 Router IPsec Configuration IPsec Parameters VNS3 Peering Mesh Setting Topology Name VNS3 Overlay Network Snapshot Management VNS3 Event Alerting Network Address Translation Traffic inspection SNMP Support VNS3 BGP Configuration Guide Remote Support Resetting VNS3 Upgrading VNS3 Release Notes VNS3 EOL Policy and Milestones IPSec Connection Checklist VNS3 Known Issues VNS3 Specifications VNS3 VPN Client tools VNS3 Control Center VNS3 setup
VNS3 Known Issues

Table of Contents

These are the Known Issues affecting runtime operations or negotiation interoperability. For more general bug fixes please review VNS3 Controller Release Notes.

BETA Version 6.0

Initially Released April 29th, 2022

6.0.0 Beta(2) - 6/1/22

  • KNOWN ISSUE: Built in Firewall Rule needs “space” character removed.
    There is a set of firewall rules built in for NAT-ing traffic to the Internet. One of them has a space character in it - which we are not removing - causing the rule installation to fail. In the rule below, edit it and remove the space character between NEW and ESTABLISHED.
    “FORWARD -i eth0 -ctrack NEW, ESTABLISHED,RELATED -j ACCEPT”
  • KNOWN ISSUE: Clientpack name tags fail to resolve if not “lower case”
    When naming a clientpack via the “name” tag, a system variable is automatically created for use in Firewall Rules and Firewall “Sets” (FWsets). If the tag value is all lower case characters, resolution succeeds. Mixed case and upper case do not resolve.
  • KNOWN ISSUE: Missing “Home” page text in Marketplace Free editions
    In cloud marketplaces there are pre-built editions with built in licensed capabilities. Upon logging into VNS3, the first page seen is a “home” page with information specific to the edition, along with pointers to documentation and support. This information is missing in the Free Edition.
  • KNOWN ISSUE: Changing plugin network does not recover plugins cleanly
    If the plugin network is edited to change the subnet in any way, while a plugin is running, the expected behavior is for the running container to be removed (with a warning), and the network change to be applied. The current behavior shows an error condition. The workaround is to stop/delete plugins, and re-allocate them after the network addressing changes are made.

Latest Major Version 5.0

Initially Released February 5, 2021

5.2.4 - 3/17/22

  • KNOWN ISSUE: Changing plugin network does not recover plugins cleanly
    If the plugin network is edited to change the subnet in any way, while a plugin is running, the expected behavior is for the running container to be removed (with a warning), and the network change to be applied. The current behavior shows an error condition. The workaround is to stop/delete plugins, and re-allocate them after the network addressing changes are made.

4.8.4 KNOWN ISSUES

  • SECURITY: Risks from authenticated administrators.

    None of the noted issues allow any actions by non-authenticated users. The CVEs noted below are present in underlying libraries used by this release of VNS3. The risks are all actions available to an authenticated administrator, which are for the most part less severe than any action the administrator can perform with the Web UI itself. CVE-2017-5029, CVE-2017-15412, CVE-2015-8806, CVE-2015-7581, CVE-2016-0751, CVE-2020-7595, CVE-2017-16932, CVE-2017-9050, CVE-2018-14404, CVE-2019-11068, CVE-2018-3769, CVE-2016-6316, CVE-2015-7578, CVE-2015-7580, CVE-2019-16782, CVE-2019-5419, CVE-2016-6317, CVE-2016-4658, CVE-2016-0753, CVE-2015-7577, CVE-2018-1000119, CVE-2015-7499, CVE-2019-16779

  • BUG: “Add Route” API call is improperly parsing the case where no gateway supplied.

    Workaround: The “gateway” argument must be supplied, using “” if there is no gateway to be specified.

  • BUG: Some dockerfile builds will fail due to buffer space limits

    The type of internal system call used to build plugins via Dockerfiles or Docker directories can run out of output buffer and permanently hang the build process. Workaround: Upgrade to newer VNS3 release.

  • BUG: API compatibility break in Cohesive Routing Agent

    Cohesive Routing Agent runs on Linux and Windows hosts allowing them to receive dynamic virtual network route updates. The updates are gotten via a connected-client-only API call which is allowed to get the current controller route table. That API call is broken due to an incompatible change introduced in VNS3 4.5. Workaround: Upgrade to newer VNS3 release.

4.8.3 KNOWN ISSUES

  • BUG: Packet filter type “conntrack” is a special case, but it not documented as such

    The “conntrack” type, when started, leaves long running process monitoring all interfaces for connection creation and destruction. The output is not in a directly downloadable file, but is available in plugins via the /mnt/logs/conntrack directory. The API and command line tool indicate the requirement for both ‘interface’ and ‘filter’ arguments. These are not used in this API call, but required by VNS3 parsing. Please use “any” for interface, and "” for filter.

  • BUG: Plugin image uploads must be gzipped

    The lack of specific documentation and screen instruction indicates that a plugin image upload can be done as a “tar” file. Currently the operations only fully succeed when the tar file is gzipped, ending in .gz (for example “myimage.tar.gz”

  • BUG: Change plugin network does not work via UI

    The container network has an option to be set/reset to a new CIDR via the Web UI. This option is not working. Workaround is to perform operation via API.

  • BUG: Save container as image does not work via UI

    The container system has an option to save a new container directly to an image. This option is not working. Workaround is to perform operation via API.

  • BUG: Snapshot Import Issues on rare occasions.

    The snapshot import bug fixed in 4.8.3 reduced the impact but did not fully eliminate the issue.

  • LIMITATION: MACRO_CUST “copy-to” rule give an error in the firewall “gray display” box

    The error can be ignored.

  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1+

    IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.

4.8.2 KNOWN ISSUES

  • BUG: Some older snapshot imports may cause controller failure

    Upon import of snapshots from releases older than 4.4, the controller may fail to initialize. This is fixed in 4.8.3. An alternative workaround is to import the snapshot into 4.4.3 and create a new snapshot from that which will import correctly.

  • BUG: Packet filter type “conntrack” is a special case, but it not documented as such

    The “conntrack” type, when started, leaves long running process monitoring all interfaces for connection creation and destruction. The output is not in a directly downloadable file, but is available in plugins via the /mnt/logs/conntrack directory. The API and command line tool indicate the requirement for both ‘interface’ and ‘filter’ arguments. These are not used in this API call, but required by VNS3 parsing. Please use “any” for interface, and "” for filter.

  • BUG: Plugin image uploads must be gzipped

    The lack of specific documentation and screen instruction indicates that a plugin image upload can be done as a “tar” file. Currently the operations only fully succeed when the tar file is gzipped, ending in .gz (for example “myimage.tar.gz”

  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1+

    IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.

4.6.1 KNOWN ISSUES

  • BUG: Snapshot Import Password Change. AFFECTED VERSIONS: 4.5.0+. When importing a snapshot to a VNS3 controller where the default password has not been changed, the resulting initialized VNS3 controller after snapshot import will have the same default password. The password is not changed to the password of the snapshot source VNS3 controller as it has in previous versions. This bug will be fixed on the next release 4.6.2.
  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1+. IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products. REMEDIATION: Work with your connecting party and configure both sides to use NAT-T. POSSIBLE ADDITIONAL REMEDIATION: In the VNS3 Endpoint “Extra Config” section, use “compat:encapsulation=auto” This will allow VNS3 to respond to either NAT-T or Native as the Cisco toggles back and forth over time. This has not been “PROVEN” to work across a broad set of use-cases, but may be worth trying if the Cisco Administrator is unwilling to configure for NAT-T.

4.4.3 KNOWN ISSUES

  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1+. IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products. REMEDIATION: Work with your connecting party and configure both sides to use NAT-T. POSSIBLE ADDITIONAL REMEDIATION: In the VNS3 Endpoint “Extra Config” section, use “compat:encapsulation=auto” This will allow VNS3 to respond to either NAT-T or Native as the Cisco toggles back and forth over time. This has not been “PROVEN” to work across a broad set of use-cases, but may be worth trying if the Cisco Administrator is unwilling to configure for NAT-T.
  • BUG: Interface Route Type for VTI Tunnel Interfaces are lost on Reboot and Tunnel Down. AFFECTED VERSIONS: 4.4.1 - 4.4.3. Routes for IPsec VTI route-based tunnels created with the “Interface Route” type can be lost on VNS3 Controller reboot or when the associated VTI tunnel goes down. After a reboot or tunnel down/up the “Interface Route” routes will be displayed via the UI/API but will not work. REMEDIATION: Use the “Route-based VPN Tunnel” Route Type when setting routes up for traffic over VTI tunnels as these persist through reboots and tunnel down/up events.

4.4.2 KNOWN ISSUES

  • BUG: There is a combination of older clientpacks which have been imported from 3.x into 4.x which are having import problems into 4.4.1-4.4.2 AFFECTED VERSIONS: 4.4.1-4.4.2. We are still chasing the cause of behavior and then will release a 4.4.3 with fix and provide manual patching if needed.
  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1/4.4.2. IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products. REMEDIATION: Work with your connecting party and configure both sides to use NAT-T. POSSIBLE ADDITIONAL REMEDIATION: In the VNS3 Endpoint “Extra Config” section, use “compat:encapsulation=auto” This will allow VNS3 to respond to either NAT-T or Native as the Cisco toggles back and forth over time. This has not been “PROVEN” to work across a broad set of use-cases, but may be worth trying if the Cisco Administrator is unwilling to configure for NAT-T.
  • BUG: Interface Route Type for VTI Tunnel Interfaces are lost on Reboot and Tunnel Down. AFFECTED VERSIONS: 4.4.1 - 4.4.3. Routes for IPsec VTI route-based tunnels created with the “Interface Route” type can be lost on VNS3 Controller reboot or when the associated VTI tunnel goes down. After a reboot or tunnel down/up the “Interface Route” routes will be displayed via the UI/API but will not work. REMEDIATION: Use the “Route-based VPN Tunnel” Route Type when setting routes up for traffic over VTI tunnels as these persist through reboots and tunnel down/up events.

4.4.1 KNOWN ISSUES

  • LIMITATION: Reset Endpoint API Call Changes IKEv2 to IKEv1. AFFECTED VERSIONS: 4.3.4+. When using the POST /api/ipsec/endpoint/:id API call to reset all Security Associations for a specific Endpoint (Phase1 SA and all tunnel Phase2 SAs) IF the endpoint is configured to IKEv2, the reset will switch the IKE version to IKEv1.
  • LIMITATION: IKEv2 Constraints (Reduced). AFFECTED VERSIONS: 4.4.1. IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
  • API CHANGE. AFFECTED VERSIONS: 4.4.0/4.4.1. Backward compatibility issues: Using the “gre”:”false” parameter in creating a standard policy-based vpn creation throws an incorrect parameter error. This condition is a “no op” and should be ignored and converted properly.
  • BUG: Interface Route Type for VTI Tunnel Interfaces are lost on Reboot and Tunnel Down. AFFECTED VERSIONS: 4.4.1 - 4.4.3. Routes for IPsec VTI route-based tunnels created with the “Interface Route” type can be lost on VNS3 Controller reboot or when the associated VTI tunnel goes down. After a reboot or tunnel down/up the “Interface Route” routes will be displayed via the UI/API but will not work. REMEDIATION: Use the “Route-based VPN Tunnel” Route Type when setting routes up for traffic over VTI tunnels as these persist through reboots and tunnel down/up events.

4.3.11 KNOWN ISSUES

  • LIMITATION: Reset Endpoint API Call Changes IKEv2 to IKEv1. AFFECTED VERSIONS: 4.3.4+. When using the POST /api/ipsec/endpoint/:id API call to reset all Security Associations for a specific Endpoint (Phase1 SA and all tunnel Phase2 SAs) IF the endpoint is configured to IKEv2, the reset will switch the IKE version to IKEv1.
  • LIMITATION: IKEv2 Constraints. AFFECTED VERSIONS: 4.3.4+. If IKEv2 is required with more than one policy, then VNS3 needs to be the rekey responder. This is achieved by setting VNS3 lifetimes to 24 hours, and connecting party to 8 hours, alternatively set VNS3 lifetimes to 8 hours, and connecting party to 1 hour. IKEv2 has limited interoperability industry wide. Another general rule is DO NOT use PFS. Improvements where VNS3 can be rekey initiator are being tested, but different issues across vendors will still require careful coordination of parameters.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products. REMEDIATION: Work with your connecting party and configure both sides to use NAT-T. POSSIBLE ADDITIONAL REMEDIATION: In the VNS3 Endpoint “Extra Config” section, use “compat:encapsulation=auto” This will allow VNS3 to respond to either NAT-T or Native as the Cisco toggles back and forth over time. This has not been “PROVEN” to work across a broad set of use-cases, but may be worth trying if the Cisco Administrator is unwilling to configure for NAT-T.

4.3.10 KNOWN ISSUES

  • BUG: Container Logs Not Displayed. AFFECTED VERSIONS: 4.0+. On the Containers page there is an option to display logs for plugins which are running. The logs are not being displayed.
  • BUG: “Add Route” API Compatibility Issue. AFFECTED VERSION: 4.3.10. API “add route” call not fully backward compatible. Some arguments are not parsed identically to previous releases.
  • BUG: NATIVE/NAT-T IPsec import toggle. AFFECTED VERSIONS: 4.0+. NATIVE/NAT-T toggle on 3.x, 3.5.x snapshot imports can occur. When importing a native IPsec connection via snapshot from 3.5.x, 3.0.x, it can be improperly configured on import to NAT-T. The remediation is to notice VNS3 using port 4500 instead of Protocol 50/ESP and toggle the configuration button to disable NAT-T.
  • BUG: DPD scheduling error. AFFECTED VERSIONS: 4.3.10. DPD scheduling is not always ocurring. In 4.3.10 Dead Peer Detection is sometimes not being scheduled and DPD probes are not being sent.
  • LIMITATION: IKEv2 Constraints. AFFECTED VERSIONS: 4.3.4+. If IKEv2 is required with more than one policy, then VNS3 needs to be the rekey responder. This is achieved by setting VNS3 lifetimes to 24 hours, and connecting party to 8 hours, alternatively set VNS3 lifetimes to 8 hours, and connecting party to 1 hour. IKEv2 has limited interoperability industry wide. Another general rule is DO NOT use PFS. Improvements where VNS3 can be rekey initiator are being tested, but different issues across vendors will still require careful coordination of parameters.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products. REMEDIATION: Work with your connecting party and configure both sides to use NAT-T. POSSIBLE ADDITIONAL REMEDIATION: In the VNS3 Endpoint “Extra Config” section, use “compat:encapsulation=auto” This will allow VNS3 to respond to either NAT-T or Native as the Cisco toggles back and forth over time. This has not been “PROVEN” to work across a broad set of use-cases, but may be worth trying if the Cisco Administrator is unwilling to configure for NAT-T.

Earlier 4.0 Known Issues

  • LIMITATION: IKEv2 Constraints. AFFECTED VERSIONS: 4.3.4+. If IKEv2 required with more than one policy, then VNS3 needs to be the rekey responder. This is achieved by setting VNS3 lifetimes to 24 hours, and connecting party to 8 hours, alternatively set VNS3 lifetimes to 8 hours, and connecting party to 1 hour. IKEv2 has limited interoperability industry wide. Another general rule is DO NOT use PFS. Improvements where VNS3 can be rekey initiator are being tested, but different issues across vendors will still require careful coordination of parameters.
  • LIMITATION: VNS3 will not auto-negotiate AES256, sha1 or sha2, with DH group 2. AFFECTED VERSIONS: 4.3.8+. AES256-SHA1-DH2 is somewhat undefined in the industry, and in the past did not cause problems, but we are now seeing interoperability errors as a result. If your partner requires this combination you must set it in the VNS3 configuration explicitly.
  • UNDER INVESTIGATION: Cisco ASA NAT-T/Native IPsec Flip. AFFECTED VERSIONS: 4.3+. In an update to VNS3 IPsec subsystem starting in 4.3.4 we are seeing Native IPsec connections (Protocol 50) be auto-detected as NAT-T by some Cisco configurations. It sometimes happens immediately, sometimes first rekey, sometimes weeks before a rekey occurs that flips to NAT-T. We have not been able to reproduce this in our lab, and have not been able to isolate it to specific Cisco configurations/revisions. It can be recognized in the network sniffer by UDP 4500 traffic (NAT-T) coming from a Cisco peer that was previously sending Protocol 50 (ESP). We have no reported cases of this interoperating with any other vendor products.
  • BUG: Overlogging and too rapid phase1/phase2 connection retries. AFFECTED VERSIONS: 4.3+. Changes in 4.3.8 reduced this but there are still occurrences where VNS3 is negotiating a phase1 with the peer device, upon success and moving to phase2, the peer device deletes the phase1 SA, and negotiation begins again. This can occur 100+ times per second putting pressure on the log files if allowed to run for many days. The rapid renegotiation attempts can be seen in the tunnel logs, and also recognized via the network sniffer. WORKAROUNDS: Disable the tunnels in question to stop the negotiation attempts. Confirm negotiation parameters with connecting partner. Usually it involved PFS enabled when it should not be, or disabled when it should be.
  • LIMITATION: IKEv2 Constraints. AFFECTED VERSIONS: 4.0-4.3.8. IKEv2 with more than one policy not supported. Do not use PFS.
  • LIMITATION: VNS3 will not auto-negotiate AES256, sha1 or sha2, with DH group 2. AFFECTED VERSIONS: 4.3.8+. AES256-SHA1-DH2 is somewhat undefined in the industry, and in the past did not cause problems, but we are now seeing interoperability errors as a result. If your partner requires this combination you must set it in the VNS3 configuration explicitly.
  • BUG: Internal NAT-T firewall rule can be lost. AFFECTED VERSIONS: 4.0-4.3.5. A combination of add/edit/deletes of IPsec endpoints on a controller could cause NAT-T endpoints to lose their connection. This was due to an internal firewall rule being inadvertently removed. WORKAROUND: Cohesive provided customers with a remediating firewall rule which can be manually entered.
  • BUG: “Ping host” source IP was not correct. AFFECTED VERSIONS: 4.0-4.3.5. VNS3 has a site-to-site VPN monitor function called “Ping Host” which periodically sends traffic over a tunnel to prevent the connecting party from doing “idle timeouts” of the VPN. When editing the ping host entry for a tunnel, it is possible that the source address is not set for the “ping” command. This can be seen visually in the web ui, and requires “toggling” the interface setting between eth0 and tun0 in order for it to be properly set.
  • BUG: DPD does not always successfully clear out the phase1 connection. AFFECTED VERSIONS: 4.0-4.3.3. A regression in the underlying IPsec library causes DPD to not always work as expected. In this case the phase1 connection might not be reset.
  • BUG: BGP “best path route” lost in 2 controller clusters. AFFECTED VERSIONS: 4.0-4.3.3. Re-saving cluster peering information could cause a BGP “best path route” to be lost in 2 controller configurations. WORKAROUND: Reboot controller 2 after save of peering information.
  • BUG: IPsec subsystem hang. AFFECTED VERSIONS: 4.0-4.3.2. A rare failure of the IPsec subsystem the conditions of which have not been reproduced in the Cohesive Networks Lab. WORKAROUND: Reboot controller or contact Cohesive Networks Support to recover the subsystem via Remote Support Access.
  • BUG: License and overlay address attributes can fail to be synchronized in multi-peer controllers. AFFECTED VERSIONS: 4.0-4.3.2. WORKAROUND: Cohesive Network remote support action.
  • BUG: Client Import of VNS3 Snapshot from Controller using default addressing and Clientpack Upgrade License. AFFECTED VERSIONS: 4.0-4.0.1. When importing a pre-4.0 snapshot which had the older addressing scheme (a /30 or 4 address block for each overlay address) and there was one or more clientpack upgrades in the existing snapshot not all overlay addresses where setup correctly. WORKAROUND: Import snapshot into 4.0.10 controller.
  • BUG: NAT-Traversal encapsulation and Native IPsec on single controller does not always work. AFFECTED VERSIONS: 4.0-4.0.8. The new feature allowing both NAT-T and Native IPsec on a single controller did not work consistently. WORKAROUND: Upgrade to 4.0.10 controller.
  • BUG: Snapshot imports from some older releases fail. AFFECTED VERSIONS: 4.0-4.0.8. Issue with Snapshot import backward compatibility to allow import of Snapshots created on much older versions of VNS3. WORKAROUND: Import into 4.0.10 or later controller.
  • BUG: IPsec subsystem restart fails. AFFECTED VERSIONS: 4.0-4.0.1. WORKAROUND: Upgrade to 4.0.10 or later.

3.5 Product Versions

  • LIMITATION: NO IKEV2 support. AFFECTED VERSIONS: All releases prior to 4.0+.
  • BUG: IPsec subsystem can become a runaway process and restart IPsec subsystem fails. Very rare. WORKAROUND: Reboot controller. AFFECTED VERSIONS: 3.5.2.
  • BUG: The reset_defaults feature was incorrectly reverts the API password to the original default password. AFFECTED VERSIONS 3.5-3.5.1.10.
  • BUG: License import was incorrectly parsing some address combinations. WORKAROUND: Use different overlay range. AFFECTED VERSIONS 3.5-3.5.1.10.
  • BUG: Imported snapshots containing Controller additions do not import properly. WORKAROUND: Upgrade to 3.5.0.8. AFFECTED VERSIONS: 3.5 – 3.5.0.6.
  • BUG: Tunnels made without descriptions could cause Web UI display errors or API call errors. AFFECTED VERSIONS: 3.5 – 3.5.0.5.
  • BUG: NAT-ing issues can occur in environments where ETH1 is the “outer” network adapter instead of eth0. AFFECTED VERSIONS: 3.5 – 3.5.0.5.
  • BUG: A BGP route can be lost when doing transitive routing for an Amazon VPC mesh. AFFECTED VERSIONS: 3.5 – 3.5.0.5.
  • BUG: The autonomics system agent can fail, causing other processes to not be healed/restarted. AFFECTED VERSIONS: 3.5 – 3.5.0.5.

Updated on 16 Aug 2019

Table of Contents