Any user with the VPN access option checked on the Management Users page can access the local network via the Cipafilter's end-user (client-to-server) VPN services, if enabled. The following protocols are supported:
Secure, easy to use, and supported by all major desktop and mobile operating systems, L2TP is the recommended protocol for end-user VPN access. Cipafilter's implementation uses a pre-shared key (PSK) instead of certificate-based authentication — this makes it much simpler to deploy and use, but it is essential to the security of the tunnel that the chosen PSK be long and complex, and that it not be made public. A PSK that balances complexity with user-friendliness is auto-generated when the L2TP option is selected, but, generally speaking, the longer and more complex the PSK, the better.
PPTP is an older, simpler protocol which has traditionally been very common, especially on Windows machines. However, it is now considered insecure, and it is gradually being phased out — ChromeOS, iOS 10+, and macOS 10.12+ do not support it. Cipafilter retains this protocol strictly for backwards compatibility; it is not recommended.
IPsec tunnels are supported for site-to-site (router-to-router) VPNs. Cipafilter's implementation uses IKEv1/ESP with "next generation" cryptographic suites for the greatest security and performance.
Although these technologies are industry-standard and in wide deployment, the site-to-site VPN functionality is designed primarily to interconnect two Cipafilter units — it may or may not function with other devices. If you would like to create a site-to-site VPN with a third-party device, Cipafilter support will try to assist you, but compatibility is not guaranteed.
| Phase | Setting | Value |
|---|---|---|
| 1 (IKEv1) | exchange mode | main |
| 1 (IKEv1) | NAT traversal | enabled |
| 1 (IKEv1) | DPD (Dead Peer Detection) | enabled, 10 second interval |
| 1 (IKEv1) | authentication method | PSK (shared secret) |
| 1 (IKEv1) | encryption algorithm | AES-256 (CBC) |
| 1 (IKEv1) | integrity (hash) algorithm | SHA-256 (HMAC) |
| 1 (IKEv1) | DH (PFS) group | MODP 4096 (group 16) |
| 2 (ESP) | key lifetime | 6 hours (21600 seconds) |
| 2 (ESP) | encryption algorithm | AES-256 (16-byte GCM) or AES-256 (CBC) |
| 2 (ESP) | authentication algorithm | AES-256 (16-byte GCM) or SHA-256 (HMAC) |
| 2 (ESP) | DH (PFS) group | NIST ECP-384 (group 20) or MODP 4096 (group 16) |
| Phase | Setting | Value |
|---|---|---|
| 1 (IKEv1) | encryption algorithm | 3DES (CBC) |
| 1 (IKEv1) | integrity (hash) algorithm | MD5 (HMAC) |
| 1 (IKEv1) | DH (PFS) group | MODP 1024 (group 2) |
| 2 (ESP) | encryption algorithm | AES-128 (CBC) or 3DES (CBC) |
| 2 (ESP) | authentication algorithm | SHA-1 (HMAC) or MD5 (HMAC) |
| 2 (ESP) | DH (PFS) group | MODP 768 (group 1) |
Site-to-site tunnels are routed upon configuration, but they are not actually established until traffic is detected which needs to flow across the tunnel. It is normal for a tunnel to not appear in the list of active SAs if it has just been configured for the first time or has not been used within the last few hours.
Endpoints may only form tunnels with a filter via its primary IP address (which is displayed at the top of every page on the Web management interface) — the use of a DNS name or secondary IP address will cause an identification failure between the two endpoints.
Multiple tunnels may be formed between the same two endpoints if the local or remote subnet differs. Phase 1 (IKEv1) SAs will be shared when possible.
When a filter has multiple tunnels configured with the same peer, that peer must not reuse request IDs. Since older versions of Cipafilter firmware were designed to work this way, it is not possible to maintain multiple tunnels with a single filter running pre-9.2 firmware, even if legacy mode is enabled.