addrblock plugin

The addrblock plugin implements traffic selector narrowing and authentication of the local and remote subnets against the IP address fields in X.509 certificates, as standardized in RFC 3779.


If a peer certificate contains IP address blocks in the proper field, it enforces that its certificate chain contains the required address blocks.


The plugin is configured using the following strongswan.conf options.

Key/Description Default
charon.plugins.addrblock.strict yes
If set to yes, a subject certificate without an addrblock extension is rejected if the issuer certificate has such an addrblock extension. If set to no, subject certificates issued without the addrblock extension are accepted without any traffic selector checks and no policy is enforced by the plugin.

The pki tool supports the issuing of certificates with address blocks using the --addrblock <address block> argument.

Use cases

  • A hub-and-spoke topology where strongSwan with the addrblock plugin is set up as the hub and a proper configuration is used to narrow the requested CHILD_SAs of the spokes to their corresponding allowed local subnets.
    For example such a configuration could be used on the hub:
            right = %any
            rightca = "C=CH, O=Linux strongSwan, CN=strongSwan Root CA" 
            leftsubnet =
            rightsubnet =
            leftid =
            leftcert = /etc/ipsec.d/certs/certificate_hub.pem
            fragmentation = yes
            leftsendcert = always
            dpdaction = clear
            auto = add

    Such a configuration obviously only works for the spokes, if they are keeping the VPN up by themselves, because the connections are not routed locally or initiated locally automatically, because there is no configuration for it. Such a scenario works for remote peers that (try to) keep up the VPN by themselves. In any case, traffic shunting using iptables should be used to make sure no traffic leaks into the WAN.

  • A theoretical alternative way to assign virtual IPs by storing it in the remote peer's certificate, using an initial traffic selector of == That way the traffic selector will be narrowed to the remote peer's VIP on its side and will/might be narrowed to the local configured subnet, or the subnet that is stored in the local peer's certificate or a subset of it.

Noteworthy issues

  • The complete chain from the root certificate to the leaf/peer certificate needs to contain the proper address blocks or a subset of a/some block(s) of the issuing certificate. If that is not the case, authentication will fail and charon will log a corresponding error message telling you that the issuer certificate lacks the address block.
    • Examples:
    • valid: issuer has, issued certificate has
    • valid: issuer has, issued certificate has
    • invalid: issuer has, issued certificate has
    • invalid: issuer has, issued certificate has