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
