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

[Harald Dunkel]

Hi Tobias,

On 6/5/18 6:55 PM, Tobias Brunner wrote:
> 
> 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.

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

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


Regards
Harri