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
