Use the Global Settings UI to configure SPA mode
Use the Client Profiles UI to create new Client profiles
If you think the use of SPA might be causing connectivity problems, refer to the user/device troubleshooting section.
Single Packet Authorization (SPA) keys are used throughout the Collective:
Keys used for peer-to-peer connections are automatically generated by the Controller.
Keys for client to Gateway SPA access are generated by the Controller uniquely for each Gateway and are included in relevant entitlement tokens.
The generation of keys is internal and requires no admin or user interaction. Because of the use of multiple Gateway keys, multi-tenant environments are supported as long as each tenant has policies that limit access to their own Gateways.
Clients need an SPA key to be able to connect to the Controller; client profiles are used for this purpose. One or more client profiles are created for the Collective that will include the SPA key. These client profiles are distributed as a special profile link, as a QR code, in an email template, or embedded into an onboarding web page. Multiple profiles can be generated for the client, each with a different SPA key. In a multi-tenant environment, each tenant can be issued their own keys. Only the keys relating to client profiles listed in the admin UI will be tied by the Controllers when a client connects.
SPA operation
SPA use can be configured in one of two ways:
TCP (as TLS extension). Before a TLS session can be established, new connections must present a single TCP packet containing a TLS ClientHello with a specially crafted extension. If that packet is not valid, TLS packets will not pass and protect the Appliance from Zero Day attacks on the TLS or application layer. The port will still reveal that there is a TCP listener present and connection attempts will be reset. This is the default for new installations and will affect the entire Collective.
UDP-TCP (SPA-DNS on 53 & SPA-DTLS on 443) + TCP (as TLS extension). New connections must present a valid UDP packet containing a time-based key. Only when a valid UDP packet is received will the TCP TLS port 443 be opened. UDP is implicitly hidden so with the TCP listener hidden behind then appliance firewall, the appliance is cloaked. Connection attempts will get no response.
The allow rule (for port 443) in the appliance firewall might be for a shared IP address (NAT), so the TCP SPA process is then followed to ensure each TCP session is handled independently.
UDP-TCP offers significant benefits in terms of DoS hardening. Firstly, it is hard to find a fully cloaked appliance, and secondly UDP packets can be easily processed at high rates, allowing stronger resilience against DOS attacks. UDP-TCP should not be considered as a complete solution to DoS. However, it does increase the point at which valid users see degraded performance compared to TCP, where degradation can be seen from about 2000 connections per second. With UDP-TCP, Appgate SDP will continue to operate even when subject to more than one million DoS packets per second.
NOTE
These specially crafted SPA handshake packet(s) must be received before a TLS/DTLS connection can be established with an appliance. SPA packets on port 53 (UDP) and on port 443 (UDP and/or TCP) are always sent regardless of the Global Settings configuration SPA use. This is done because the connecting device does not know the configuration setting of the receiving device.
For TCP SPA, the packet sent to port 443 (TCP) must be allowed through.
For UDP-TCP SPA, packets are sent to port 53 (UDP) and 443 (UDP), at least one of which must get through. If TLS is being used for the tunnel, the system will subsequently perform TCP SPA, so the packet sent to port 443 (TCP) must also be allowed through.
SPA overrides
The SPA override feature allows the SPA mode to be changed for a specific appliance. This is useful when the global SPA mode is not appropriate for every situation. For example:
When a Site with two Gateways needs added security, then UDP-TCP SPA mode could be enabled for just these two appliances.
When users have issues connecting from some locations and a fallback Gateway could be set to allow the use of TCP SPA mode.
When using this feature, note that the connections to Controllers and Gateways are all made independently of one another:
When upgrading to UDP-TCP SPA mode, this is not an issue.
When downgrading to TCP SPA mode, one Controller and one Gateway from each Site must have SPA override enabled or the Client may be only partially operational, This also implies that you must have at least two Controllers configured and at least two Gateways per Site. There is the option to set the downgraded Gateway appliances to a low or zero weighting, but there is no real benefit to doing this. The main benefit of UDP-TCP SPA is DoS hardening, and the Collective will still be hardened because any users connecting to a DoS-ed TCP appliance will be failed over to a UDP-TCP one. Furthermore, the users relying on the TCP override feature will failover faster, as they will not always have to wait for the last low or zero weighted appliance.
The per-appliance override feature for SPA can be configured in System TLS Connection (Using SPA).
Alternatively, you can modify the behavior of SPA UDP-TCP globally, which may work in situations where there are a few well-defined exceptions that need to be handled. This can be configured using cz-config.