[strongSwan] IKEv2: how to set the DNS search attribute on the peer?

Harald Dunkel harald.dunkel at aixigo.com
Mon Jul 1 14:14:13 CEST 2019

Hi Tobias,

On 7/1/19 10:41 AM, Tobias Brunner wrote:
>> AFAICT NetworkManager would like to call resolvconf itself, but apparently
>> it is missing the DNS domain.
> Is a search domain actually required in your setup?  Because, as I said,
> there is no standardized IKEv2 attribute for it at all.

Yes, definitively. My colleages are used to openvpn and its NetworkManager
plugin, supporting several "dhcp-options", including domain search list.

IPsec configuration on a road warrior laptop appears to be more difficult.
 From an admin point of view, it would be much easier and less error-prone
to define the search list at a central location on the gateway than in the
Network Manager gui on every road warrior laptop.

>> Of course the documentation states: "Cisco Unity extensions for IKEv1"
>> but I don't see any reason why this shouldn't work for IKEv2 as well
>> (except for not being listed in some document).
> Why would configuration attributes for a proprietary IKEv1 extension,
> with numbers from the private use range, work with IKEv2? 

I just showed the current contents of my config file. We are not using IKEv1,
but the code was still there from my very first days with Strongswan. Of
course I don't expect Cisco's private extension numbers to work.

What I meant is, would you agree that strongswan could define its own private
extension for IKEv2, similar to Cisco's IKEv1 extension? Obviously strongswan
can forward some DNS server IP addresses to the peer, using the remote
resolvconf tool to setup /etc/resolv.conf. I thought it might be just a small
step to push a domain search string to the peer as well.

> Granted,
> since it's not possible to set an IKE version for custom attributes in
> the attr plugin's configuration, it will just assign them as configured
> to any client that requests a virtual IP.  But a client that handles
> them would technically be non-compliant.  Anyway, strongSwan actually
> doesn't handle these Unity attributes as client at all, not even for IKEv1.

As indicated before, I wouldn't care about the documents and RFCs *not*
specifying attributes. Strongswan is highly compliant by supporting the standard
features and attributes, but supporting some extra attributes wouldn't hurt,

Anyway, strongswan is a highly important part in our infrastructure. Keep on
your good work.


More information about the Users mailing list