VNS3 Controller Known Issues

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

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

 
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: 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.
 
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: 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

 
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: 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

 
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: Exported plugin images were not being gzipped
AFFECTED VERSIONS: 4.6.1
When exporting a plugin container as a new image, the export (tar filesystem of the running container) was previously gzipped in background as system resources were available. The kernel patches previously deployed to mitigate against the Meltdown and Spectre attacks had an unanticipated impact on the library used to background the gzip task, preventing it from running with proper permissions. This but will be fixed on the next release. 
 
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.
 
LIMITATION: IKEv2 Constraints (Reduced)
AFFECTED VERSIONS: 4.4.1+
IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
 
RESOLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+
UPDATE:  This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works. 
If you want Native IPsec the Cisco administrator MUST configure their device properly.  See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
HISTORY: 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.

4.4.3 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
 
LIMITATION: IKEv2 Constraints (Reduced)
AFFECTED VERSIONS: 4.4.1+
IKEv2 interop limitations have been reduced to PFS. Please use IKEv2 with PFS disabled.
 
RESOLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+
UPDATE: This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works. 
If you want Native IPsec the Cisco administrator MUST configure their device properly. See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
 
HISTORY: 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: 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

 
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: 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.
 
REOSLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+
UPDATE: This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works. 
If you want Native IPsec the Cisco administrator MUST configure their device properly. See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
 
HISTORY: 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: 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

 
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
 
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

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
 
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.
RESOLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+
UPDATE: This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works.
If you want Native IPsec the Cisco administrator MUST configure their device properly. See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
HISTORY: 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.

4.3.10 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: 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.
 
RESOLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+
UPDATE: This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works. 
If you want Native IPsec the Cisco administrator MUST configure their device properly. See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
 
HISTORY: 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. 
 

Earlier 4.0 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
 
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.

RESOLVED: Cisco ASA NAT-T/Native IPsec Flip
AFFECTED VERSIONS: 4.3+

UPDATE: This is due to a misunderstanding by most Cisco administrators in how their ASA/ASR/ISR works.
If you want Native IPsec the Cisco administrator MUST configure their device properly. See this knowledge base article: https://support.cohesive.net/a/solutions/articles/31000149860
HISTORY: 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 VERSION: 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 VERSION: 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