How to Choose Site-to-Site VPN Gateways That Interoperate

Two site gateways from different vendors will form a tunnel if their implementations agree on the parameters that get negotiated. Identical brands are not a requirement, and matching brands are not a guarantee either. The compatibility question is about features and releases; the capacity question is about work the device has to do in software. Treat them as two checks, in that order.

Work down the list and stop at the first item that has no answer.

Start from the protocol features, not the brand

For the protocol you intend to run, list what the design needs: authentication method, agreed encryption and integrity proposals, the interface or protected-traffic construct, routing mode, and whether either side sits behind NAT. Each is a feature the implementation must support, not a checkbox on a product page.

AWS's customer gateway requirements are a useful template even if you are not connecting to AWS, because they state the contract as a set of protocol and routing obligations. A vendor sample file for a specific model is decent evidence that someone tested that combination. A generic label claiming IPsec support proves neither the version nor the policy model. Read the release notes rather than the marketing summary.

Check the release, not the datasheet label

IKEv2 interoperability is decided by negotiated parameters, so the question is which proposals the current firmware offers and accepts. A device that supports the protocol in general can still refuse the specific combination your other end insists on. Confirm the version string and the proposal list on both sides.

A note that a feature arrived in a later firmware train is common enough to deserve its own checklist item.

Treat capacity as a separate question

Encryption costs work, and how much depends on the implementation as much as on the algorithm. Some acceleration paths apply only to particular algorithms or particular forwarding paths, so a device can be fast in one configuration and slow in another. Ordinary WAN throughput is not encrypted tunnel throughput. Size the device against the traffic you will actually protect.

Packet size matters too, because encapsulation and any additional overhead reduce the payload each packet carries.

Decide the routing policy explicitly

Site-to-site does not mean only selected traffic may use the tunnel, and it does not mean everything must. A design can carry specific private prefixes, or route a default through the gateway. Choose one and write it down, because both ends have to agree on what is advertised and what is accepted. A mismatch here produces a tunnel that is up and a network that is half reachable.

Dynamically routed designs add another requirement: routing protocol support on both ends.

What to compare before you buy

Compare update cadence, interoperability evidence, configuration recovery and intended failover behaviour alongside peak transfer rate. Ask what happens when the device reboots with a stale configuration. Ask whether the vendor publishes an interoperability list for the exact peer you plan to use. Ask who owns the change when a firmware update alters a default proposal.

A hardware warranty is not an answer to any of those.

Then test the pair before committing to a fleet. One tunnel, the real proposals, the real routing mode and a transfer that resembles the workload will tell you more than any specification table.