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

[Tobias Brunner]

Hi Harald,

>> 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.

That doesn't answer the question whether it is actually required.  Just
because it's an option in some other tool, doesn't mean it is actually
used (are people really that lazy and don't type full domain names?
what about TLS?).

> IPsec configuration on a road warrior laptop appears to be more difficult.

Nobody forces you to use IPsec :-)

>  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.

Well, there is no separate attribute to exchange it, so...  I guess a
client that supports INTERNAL_DNS_DOMAIN attributes could install the
same as search domains (maybe optionally) but not sure if that's what
people expect or if that would have some side-effects (not sure if NM
does that already as it only has one option that takes multiple domain
names, maybe it uses them for both, or it only supports search domains).

Scripting/importing NM configs might also be an option to make local
configuration easier for users.

> 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.

I guess, but it's not a nice solution at all (identifiers from the
private use range are very problematic and require exchange vendor ID
payloads).  You could go the IETF route and write an Internet Draft that
defines such a configuration attribute if you really see a need for it.

> 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,
> IMHO.

I don't agree with that at all.  But you are free to write your own
plugin that does whatever you want and deploy that to your clients.

Regards,
Tobias