dhcp Plugin

Purpose

The dhcp plugin for libcharon allows to forward requests for virtual IP addresses to a DHCPv4 server.

The plugin is disabled by default and can be enabled with the ./configure option

--enable-dhcp

Behavior

When an IKEv2 client requests a virtual IP address via a CP 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.

The MAC address used in the DHCP request is either randomly generated or can optionally be based on the IKEv2 identity of the client. DNS/WINS server information is additionally served to clients if the DHCP server provides such information.

In combination with the farp plugin this plugin lets a road-warrior fully act as a client on the local LAN of the responder.

Configuration

The following entry in swanctl.conf enables the plugin for a connection:

connections.<conn>.pools = dhcp

The dhcp plugin is configured using the following options in the charon.plugins.dhcp section of strongswan.conf:

Key Default Description [Default]

Key	Default	Description [Default]
force_server_address	`no`	Always use the configured server address^[1]
identity_lease	`no`	Derive user-defined MAC address from hash of IKE identity. The client identity `DHCP` option containing the IKE identity is only sent if this option is enabled
interface		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
interface_receive	[→]	Interface name the plugin uses to bind its receive socket. The default is to use the same interface as the send socket. Set it to the empty string to avoid binding the receive socket to any interface while the send socket is bound to one. If the server runs on the same host and the send socket is bound to an interface, it might be necessary to set this to `lo` or the empty string. Since version 6.0.1
server	[→]	`DHCP` server unicast or broadcast IP address. `[255.255.255.255]`
use_server_port	`no`	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^[2]

force_server_address

no

Always use the configured server address^[1]

identity_lease

no

Derive user-defined MAC address from hash of IKE identity. The client identity DHCP option containing the IKE identity is only sent if this option is enabled

interface

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

interface_receive

[→]

Interface name the plugin uses to bind its receive socket. The default is to use the same interface as the send socket. Set it to the empty string to avoid binding the receive socket to any interface while the send socket is bound to one. If the server runs on the same host and the send socket is bound to an interface, it might be necessary to set this to lo or the empty string. Since version 6.0.1

server

[→]

DHCP server unicast or broadcast IP address. [255.255.255.255]

use_server_port

no

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^[2]

1. If the DHCP server runs on the same host as the daemon with DHCP plugin, you may need to enable dhcp.force_server_address and then set 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.

2. 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 unreachable message will be sent back that 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, ICMP messages should not be an issue.