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

[Tobias Brunner]

Hi Harald,

>> 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).
>>
> 
> My IPsec gateway provides a separate subnet for the peers. dnsmasq is
> the only dhcp/dns server on this subnet.

So you mainly use it as DNS server to map names of your clients to their
virtual IP?

> Do you think it would be possible to add some "dyndns" feature to
> strongswan's IP address pool? The dhcp discover takes about 3 seconds
> (at least for dnsmasq). I would love to get rid of this.

I guess you could write a plugin (or script) that (un-)registers the
assigned virtual IP at a DNS server (if it provides an API for it, e.g.
RFC 2136).

>>> 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.
>>
> 
> Using your patch in the dhcp-client-port branch and "force_client_port = yes"
> the dhcp support in 5.6.3 is working again (for me).

OK, great.

> For backwards compatibility I would suggest to keep port 68/udp by default.
> Its a serious cut dropping an old hard-wired port number in favor of a new
> one, just because some dhcp servers might have a problem with the ICMP port
> unreachable triggered on Linux. I think its pretty common to run both IPsec
> and DHCP on the same gateway.

Let's see if there are others having issues with this first.

Regards,
Tobias