farp plugin conflicts with DHCP service
Looking on the surface, the cause of this conflict is the farp plugin. OK. Both StrongSwan and ISC-DHCP were deployed on a same machine. And the DHCP use a pool to assign IP addresses to regular clients. Also there is a fixed IP assignment rule for one client which use site2site strongSwan encapsulation.
So, if I load the farp plugin, those regular clients can retrieve IP addresses from ISC-DHCP server. However, for the client that will go through the site2site tunnel, it failed. The macOS system noticed me that the predefined fixed IP address had already been taken, even if it was not in reality. And during this moment, if I ran the command of `ipsec stop`, the client immediately successfully retrieve the predefined IP address.
#1 Updated by Tobias Brunner over 1 year ago
- Status changed from New to Feedback
#2 Updated by Tom Hsiung over 1 year ago
Thank you for your respond, Tobias.
According to your description. It seems that issue was caused by the fact that I have assigned a fixed IP address to my client based on its real MAC address, configured in the DHCP server. However, when farp plugin is enabled, the DHCP server (affected by the strongSwan farp plugin when the IPsec tunnel is estalished) will assign IP addresses based on the virtual MAC addresses, which are different from the clients' real physical MAC addresses. So, the real MAC defined in the DHCP server and the virtual MAC it actually used conflicted, resulting in this problem.
#3 Updated by Tobias Brunner over 1 year ago
However, when farp plugin is enabled, the DHCP server (affected by the strongSwan farp plugin when the IPsec tunnel is estalished) will assign IP addresses based on the virtual MAC addresses
The dhcp plugin does not know the client's physical MAC address, it will always request an IP with a virtual MAC address (this has nothing to do with the farp plugin). That address is optionally based on the client's identity, which you could actually use directly instead of any MAC address as it is sent to the server too if identity_lease is enabled (there are examples for both in our regression tests). However, if the DHCP server does an ARP lookup for that IP it might detect a duplicate IP if the farp plugin responds with the server's physical MAC address. However, it will only do so once a remote traffic selector that covers that IP is negotiated with a peer (e.g. if incorrect TS are configured and negotiated with other peers, or maybe during make-before-break reauthentication, although, the dhcp plugin can't handle that properly anyway).
So, the real MAC defined in the DHCP server and the virtual MAC it actually used conflicted, resulting in this problem.
I don't see any conflict with the client's physical MAC address, unless perhaps you used the server's MAC address (which is the one with which the farp plugin answers to ARP requests) or if the client is actually in the same LAN as the VPN/DHCP server (but that will produce weird effects anyway).