Concentrator or Gateway? Locating the VPN Terminator in Your Path

Two vendors can call the same box a concentrator and a gateway, and neither word will tell you where the traffic is decrypted. The labels describe deployment roles rather than protocols, and the roles overlap in every direction. What matters for a design review is the device that terminates the tunnel, the controls around it, and the path a decrypted request takes. Decide from those three, and the noun on the datasheet stops being an argument.

Two labels, one decision

A concentrator usually means the central system that receives and manages many connections at once, and the word carries an implication of scale. A gateway is the broader term for an endpoint that joins a tunnel to the networks behind it, and it can describe a router, a firewall or a managed service. Neither word names a protocol, and neither promises a particular feature set. The same appliance may be sold under both names by two vendors, which is why the terminology argument never resolves.

Treat the label as a hint about intended use and nothing more. The decision belongs to the functions you can verify in the configuration rather than to the words in the brochure.

Find the device that actually terminates

Follow a client connection from the outside in. Something accepts the transport, something authenticates the peer, something assigns the client an address, something authorises a destination, and something supplies a return route. Those five functions can live on one device or on five, and the only useful question is which device does which. An upstream router may carry the outer packets without ever decrypting them, which is exactly the case where a topology diagram misleads a reviewer into naming the wrong box.

Confirm termination on the candidate itself rather than from the drawing. A listening socket on the expected port plus an established state entry is stronger evidence than a network diagram, and the absence of both is stronger still.

sudo ss -lunp | grep -E ":500|:4500"
sudo ip xfrm state
sudo traceroute -n -U -p 4500 vpn.example.com

Decide by five properties, not by the product name

Five properties separate the candidates, and each one is answerable from documentation rather than from marketing. Which VPN roles does this release support, which identity sources can it use, what forwarding scope does it allow, how much capacity does it sustain, and how does it behave under failure. Ask for those five in writing and the label becomes irrelevant to the decision.

Capacity is the property the concentrator label implies most strongly, and it is the one most often left vague. Concurrency limits, throughput per tunnel and total throughput are three different numbers, and a device can be generous in one and stingy in another. High availability is a property of the pair rather than of either box, and it belongs in the recovery question. A label that suggests scale is not a specification of scale.

Recovery belongs in the same conversation. Ask how an administrator reaches the device when the tunnel itself is the broken component, because an out-of-band path is a design decision rather than an accessory.

Check the evidence before the label

A current service should be evaluated on supported roles, identity policy, forwarding scope, capacity and recovery behaviour, with answers specific to the version you would deploy. A historical overview can explain why the word concentrator exists, but it cannot tell you what a current release supports. The Cisco VPN overview is useful terminology context for exactly that reason, and treating it as a current feature list is how a design review goes wrong.

Then verify one claim end to end. Pick the property that matters most, such as per-tunnel throughput or failover time, and ask for the measurement method rather than the number. A quick local check of what the device actually exposes is a reasonable start.

sudo ip xfrm state | grep -c '^src '
sudo swanctl --list-sas

On Linux the first line counts security associations, and a tunnel normally has two of them, one per direction, so halve the count before comparing it with a tunnel claim. On a strongSwan host the second line names the tunnels directly. A socket count is not a substitute: IPsec NAT-T keeps a single UDP 4500 socket shared by every tunnel, so counting sockets on that port returns zero or one however many tunnels exist. Neither line is a throughput measurement, and neither predicts behaviour under load. What they give you is the unit to ask about, and a vendor who can describe the method has a specification where one who cannot has a brochure.

Write the path down and the labels stop mattering

Describe the architecture as a list of functions with owners: termination, authentication, address assignment, authorisation, return routing, logging and recovery. That description survives a product rename, a vendor change and an acquisition, none of which will update your diagram.

Review it against a real client session once a quarter, because a function can move without anyone editing the drawing. The labels will keep changing, and the list of owners will keep being the thing that actually explains the network.