[strongSwan-dev] 5.6.3 regression: dhcp integration appears to be broken

[Tobias Brunner]

Hi Harri,

>> That's because with 5.6.3 we now bind to port 67 instead of 68 if a
>> server address is explicitly configured, in which case we act as relay
>> agent and set `giaddr` in the request.  The server will send the
>> response to port 67 even if sent from port 68.  We receive messages via
>> a raw packet socket on both ports, but to avoid ICMP port unreachables
>> when receiving packets on an unbound port, we now bind port 67 instead
>> of 68.
>>
>> We set SO_REUSEADDR on the socket so this could actually work fine,
>> unless perhaps the other process doesn't do that or is bound to a
>> specific IP address (on my system I also have dnsmasq running on
>> 0.0.0.0:67, but that doesn't cause a conflict).  That's actually similar
>> if we bind port 68, which a DHCP client like dhclient might already have
>> bound.
>>
> 
> I am not sure if I got you correctly, but the server address is configured
> explicitly in dhcp.conf *because* dnsmasq is not running on all interfaces.
> It is bound to internal network interfaces only. I think its reasonable
> that both dnsmasq and strongswan ignore the external network connection
> (the line to the ISP) for dhcp and router advertisements completely.

Perhaps you could also prevent DHCP packets from leaving the host via
iptables.  Also, familiarize yourself with DHCP and then perhaps
consider not using it if you only do this locally anyway (why? - the
dhcp plugin is intended to reuse already existing infrastructure).

> If I omit the server address in dhcp.conf, then I get
> 
> Jun  6 11:15:19 12[IKE] <IPSec-IKEv2|1> peer requested virtual IP %any
> Jun  6 11:15:19 12[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 255.255.255.255
> Jun  6 11:15:19 12[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER failed: Operation not permitted
> Jun  6 11:15:19 12[CFG] <IPSec-IKEv2|1> DHCP DISCOVER timed out

Could be because your firewall blocks the broadcast packets.

> If I keep the server address in dhcp.conf and use
> 
> 	bind-interfaces
> 	except-interface=eth0
> 
> in dnsmasq.conf, then the port number conflict is gone, but dhcp is
> still broken. Now I get
> 
> Jun  6 12:01:13 23[IKE] <IPSec-IKEv2|1> peer requested virtual IP %any
> Jun  6 12:01:13 23[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 172.19.122.9
> Jun  6 12:01:14 23[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 172.19.122.9
> Jun  6 12:01:16 23[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 172.19.122.9
> Jun  6 12:01:19 23[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 172.19.122.9
> Jun  6 12:01:23 23[CFG] <IPSec-IKEv2|1> sending DHCP DISCOVER to 172.19.122.9
> Jun  6 12:01:28 23[CFG] <IPSec-IKEv2|1> DHCP DISCOVER timed out

On what interface is that IP installed?  Maybe dnsmasq ignores packets
sent to it if it doesn't consider that interface.

>> Anyway, we could probably catch that error and bind to port 68 instead
>> (as the reason to bind 67 was to avoid ICMPs, another process binding it
>> is fine).  I actually had some code that did that at one time, but since
>> some testing proved it unnecessary (to me at least), I removed it.  I
>> pushed a patch that adds it again to the dhcp-rebind branch [1].
>>
> 
> Instead of catching port number conflicts (which implies knowledge about
> the startup sequence, afaics) I would suggest to make this relay agent
> feature configurable.

Yeah, that's true.  In the dhcp-client-port branch I added an option to
force the use of the DHCP client port as source port even when acting as
relay agent.

Regards,
Tobias