In strongSwan configuration files, the auto parameter controls how VPN connections are initialized during daemon startup. The difference between auto=add and auto=start primarily lies in their activation behavior:

conn myvpn
    left=192.168.1.100
    right=203.0.113.5
    leftsubnet=10.0.1.0/24
    rightsubnet=10.0.2.0/24
    auto=add  # or auto=start

When using auto=add, the connection is:

• Loaded into memory but remains inactive
• Requires manual triggering via ipsec up myvpn
• Ideal for on-demand connections

With auto=start, the connection:

• Is loaded AND immediately established
• Persists through daemon restarts
• Suitable for always-on VPNs

Scenario 1: Temporary debugging connection

conn debug-tunnel
    auto=add
    # Configuration omitted...

Scenario 2: Production site-to-site VPN

conn prod-vpn
    auto=start
    # Configuration omitted...

Verify status with ipsec status:

# auto=add connection
myvpn:  installed but inactive

# auto=start connection
prod-vpn:  established

Combine with other parameters for precise control:

conn smart-vpn
    auto=add
    keyingtries=%forever
    dpddelay=30
    dpdtimeout=120
    dpdaction=restart

This configuration creates a connection that:

• Stays loaded but inactive initially
• Automatically reconnects if DPD detects failure
• Maintains persistent configuration

In strongSwan IPsec configurations, the auto parameter controls connection initialization behavior during daemon startup. The two most commonly debated values are:

# Example connection sections demonstrating both options
conn example-add
    auto=add
    left=192.168.1.1
    right=203.0.113.5
    [... other parameters ...]

conn example-start
    auto=start
    left=192.168.1.1
    right=203.0.113.10
    [... other parameters ...]

auto=add creates the connection configuration in memory but doesn't initiate IKE negotiations. The connection only activates when matching traffic triggers it (via kernel policies or manual startup). This is ideal for:

• On-demand VPN connections
• Scenarios where immediate connectivity isn't required
• Reducing startup overhead for complex configurations

auto=start immediately initiates IKE negotiations during daemon initialization. Use this when:

• Persistent connectivity is mandatory
• You need the tunnel established before application traffic
• For site-to-site tunnels that must always be available

The behavior difference manifests in the charon daemon's initialization sequence:

// Simplified pseudocode of strongSwan's handling
void load_connection(conn_section) {
    parse_config(conn_section);
    if (conn_section.auto == "start") {
        initiate_ike_sa(conn_section);
    } else if (conn_section.auto == "add") {
        create_policy_only(conn_section);
    }
}

Consider a hybrid setup where some tunnels should be persistent while others are on-demand:

# Always-active tunnel to headquarters
conn hq-tunnel
    auto=start
    left=10.1.0.1
    right=hq.vpn.example.com
    leftsubnet=10.1.0.0/24
    rightsubnet=10.0.0.0/16
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!

# On-demand tunnel for cloud access
conn cloud-access
    auto=add
    left=%any
    right=cloud.vendor.com
    leftsubnet=10.1.1.0/24
    rightsubnet=172.16.0.0/12
    keyexchange=ikev2
    fragmentation=yes

To verify connection states:

# List loaded connections (both add and start)
ipsec statusall

# Check specific connection policies
ipsec status cloud-access

# Manually trigger an 'auto=add' connection
ipsec up cloud-access

Using auto=start excessively can:

• Increase daemon startup time (each connection negotiates sequentially)
• Generate unnecessary IKE traffic if peers are temporarily unavailable
• Consume system resources for idle tunnels

The auto=add approach typically shows better scalability for environments with numerous potential tunnels that aren't constantly active.