[strongSwan-dev] 5.6.3 regression: dhcp integration appears to be broken
tobias at strongswan.org
Thu Jun 7 11:24:27 CEST 2018
>> 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
> 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.
>>> 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.
Let's see if there are others having issues with this first.
More information about the Dev