Skip to content
Docs sslbrain sslbrain.com

Barracuda CloudGen Firewall

Copy link to the page “Barracuda CloudGen Firewall”

← All integrations

Firewall and VPN beta

Sets the VPN service's default certificate in CloudGen and finds certificates in firewall and Control Center stores.

The appliance runs the package and connects to Barracuda CloudGen Firewall through CloudGen Firewall REST API over HTTPS on port 8443. No agent is installed on Barracuda CloudGen Firewall.

What happens

  1. The appliance connects to Barracuda CloudGen Firewall through CloudGen Firewall REST API on port 8443.
  2. Discovery reads the certificate store (from 10.0; on 9.x the older certificate list), on a Control Center also the global store and the range and cluster stores, and lists the services by name and module so the rule can name the VPN service. A 9.x Control Center has no certificate list for ranges and clusters in the REST API; they are reported as not read.
  3. Installation: the package checks that the key belongs to the certificate, opens a configuration session, reads the VPN service's settings, writes the certificate, private key and public key with the service's other keys unchanged, reads the session back and commits. A Control Center then sends the configuration to the box and waits until the box reports the update as done. If it fails: If a step before the commit fails, the session is rolled back and nothing changes. If the commit is not answered, a fresh read of the settings decides whether the certificate changed. A failure after the commit is reported as a change that needs follow-up, never as unchanged. If the Control Center's update ends in an error or cannot be confirmed, the Control Center holds the new certificate while which one the box uses cannot be read; the next attempt sends the configuration again without writing it anew.
  4. Afterwards the package reads the VPN service's state. The service is restarted only when the rule asks for it, and only on a standalone firewall; a restart ends every VPN tunnel and connection of that service. If it fails: On a standalone firewall: if the service was up before the switch and is down after it, and the settings still hold the package's certificate, the package writes back the certificate and key it read in the same run and reports a failure. A change someone else made since is not overwritten. The Control Center REST API documents no state of a managed box's service, so there the package writes nothing back.
  5. Verification: the package finds the certificate in the store by its SHA-256 fingerprint, optionally under a given name, and reports missing chain certificates and an older entry with the same name. When a store or entry could not be read whole, verification reports that it could not decide, not that the certificate is missing. When the rule names the VPN service, verification instead compares the certificate in that service's committed configuration, the one installation writes.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to CloudGen Firewall REST API, port 8443. No agent is installed.
Service ports
8443
You need
Enable the REST API (HTTPS, port 8443). Use an administrator with REST access, with a username and password or a REST API token. Read rights are enough to find and check certificates, for example a copied observer role with REST access; installing needs the Manager role for the VPN service's configuration. The rule names the VPN service as Firewall Admin lists it, and on a Control Center also the range, cluster and box.
Platform
CloudGen Firewall and CloudGen Control Center 9.0 and later with the REST API; the certificate store from 10.0
Actions
Discovery, Installation, Verification; no rollback action
Packages
barracuda-cloudgen-api 1.0.0
Note
  • Barracuda documents no REST readback of the certificate a running VPN service uses, and IPsec/TINA cannot be checked with a TLS handshake. The package therefore confirms the configuration (committed, and read back when the settings can be read; on a Control Center sent to the box) and, on a standalone firewall, the service state, and reports the installation as done with a warning.
  • The VPN service's CA chain is set in Firewall Admin (VPN Settings, Certificate Chain) and has no field in the REST API; the package leaves it as it is. When the new certificate has another issuer than the previous one, it is installed and the result warns: clients that validate the chain need the new issuer's certificates in Certificate Chain.
  • The previous key on the firewall is replaced; the package keeps the previous certificate and key only during the run, so it can write them back. An interrupted run leaves a journal on the appliance with fingerprints, never keys, and the next installation first reads what the firewall holds and reports it before it writes.
  • Version 1.0.0 installs only the VPN service's default server certificate. Certificates for SSL VPN, the REST API's own HTTPS port, management (Firewall Admin) and named VPN service certificates are not part of this version and are still selected in Firewall Admin.
  • Which service uses a certificate in the store cannot be read through the REST API. Verification reports whether the REST API port itself serves the certificate; VPN, SSL VPN and other services listen on ports the package does not connect to.
  • Discovery and verification send read requests only; installation writes only the named VPN service's settings. The REST API certificate is verified by default; a self-signed certificate on an IP address can be accepted by its SHA-256 fingerprint.
  • A high-availability partner gets the configuration through the firewall's own HA synchronisation; the package does not read the partner.
  • Barracuda Web Application Firewall is a different product with its own API and has an integration of its own.

Get started