The dhcp plugin allows to forward requests for virtual IP addresses to a DHCP server.
To enable the plugin, add
--enable-dhcpto the ./configure options.
It has been available since 4.4.0.
The plugin only supports DHCP for IPv4.
When an IKEv2 client requests a virtual IP address via a configuration payload, the plugin allows the daemon to forward this request to a DHCP server. By default the plugin uses broadcasts, but a designated DHCP server can be configured in strongswan.conf.
DNS/WINS server information is additionally served to clients if the DHCP server provides such information.
The MAC address used in the DHCP request is either randomly generated or can optionally be based on the IKEv2 identity of the client.
In combination with the farp plugin this plugin lets a road-warrior act as a client on the local LAN of the responder.
To enable the plugin for a connection the following option must be specified in ipsec.conf:
The plugin may be configured using the following strongswan.conf options.
|Always use the configured server address. See the note below for details.|
|Derive user-defined MAC address from hash of IKE identity. Since 5.6.3 the client identity DHCP option (containing the IKE identity) is also only sent if this option is enabled.|
|Interface name the plugin uses for address allocation. The default is to bind to any (0.0.0.0) and let the system decide which way to route the packets to the DHCP server.|
|DHCP server unicast or broadcast IP address.|
|Use the DHCP server port (67) as source port, instead of the DHCP client port (68), when a unicast server address is configured and the plugin acts as relay agent. When replying in this mode the DHCP server will always send packets to the DHCP server port and if no process binds that port an ICMP port unreachables will be sent back, which might be problematic for some DHCP servers.
To avoid that, enabling this option will cause the plugin to bind the DHCP server port to send its requests when acting as relay agent.
This is not necessary if a DHCP server is already running on the same host and might even cause conflicts (and since the server port is already bound, ICMPs should not be an issue).
Available since 5.7.0. In 5.6.3 this behavior was enabled automatically if anything but the broadcast address was configured as server address.
Note: If the DHCP server runs on the same host as the daemon with DHCP plugin, you may need to enable charon.plugins.dhcp.force_server_address and then set charon.plugins.dhcp.server to the local broadcast address (e.g. 192.168.0.255). That's because some DHCP daemons do not listen on the loopback interface and, thus, can't be reached via unicast (or even broadcast, 255.255.255.255) from the same host.