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

[Tobias Brunner]

Hi Harri,

> I have to run strongswan and dnsmasq (providing the address pool and DNS
> to the peers) on the same hardware. Apparently there is a conflict with
> the local dnsmasq now. I just wonder why it didn't show for 5.6.2 ?

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.

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].

> Shouldn't the dhcp plugin bind to a random socket to access 67/udp provided
> by dnsmasq?

No, unfortunately that's not how DHCP generally works.  There is a
recent RFC (RFC 8357 [2]), which relaxes the client port requirements
for DHCP relay agents, but I'm not sure if there are any DHCP servers
that implement it.

Regards,
Tobias

[1]
https://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/dhcp-rebind
[2] https://tools.ietf.org/html/rfc8357