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

[Harald Dunkel]

Hi Tobias,

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

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.

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

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.


Thanx for your help
Harri