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

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