[PATCH] write CISCO_SPLIT_INC in order

[Kevin Cernekee]

On Fri, Jul 21, 2017 at 5:23 PM, Corey Hickey <bugfood-ml at fatooh.org> wrote:
> On 2017-07-21 15:33, Daniel Lenski wrote:
>>
>> On Fri, Jul 21, 2017 at 10:15 AM, Kevin Cernekee <cernekee at gmail.com>
>> wrote:
>>>
>>> On Mon, Jul 10, 2017 at 3:44 PM, Corey Hickey <bugfood-ml at fatooh.org>
>>> wrote:
>>>>
>>>> The linked list implementation results in routes being queued in
>>>> reverse of the order in which they were received. So, when dequeuing
>>>> them, write to the buffer backwards.
>>>
>>>
>>> Unfortunately it is not clear to me which parameter you would like to
>>> reorder: search domains (from the GitHub bug), split DNS (from the
>>> patch), or included routes (from the subject line)?
>>>
>>> Search domains are sensitive to ordering, so that makes the most sense
>>> to me.  AIUI routing should use the longest prefix match + metric; and
>>> split DNS should not be sensitive to ordering since it is a whitelist.
>>
>>
>> I believe that search domains are the intended case that needs fixing.
>>
>> It seems that OpenConnect's current behavior is to send *all of these
>> lists* to the vpnc-script in the opposite order from which they are
>> sent by the VPN gateway, and that Corey's patch will — if nothing else
>> — make script debugging a bit more intuitive by showing them all in
>> the same order in which OpenConnect receives them from the server.
>
>
> The above is correct with regard to my intent, with the addition that
> sometimes the order of search domains does matter from an administrator/user
> perspective, so my ultimate goal is to correct that.
>
> I wrote about this in a bit more detail here:
> https://github.com/dlenski/openconnect/issues/40#issuecomment-313792933
>
> As far as I know, this particular patch is actually a no-op for users
> because vpnc-scripts does not actually use CISCO_SPLIT_DNS--but if this
> patch gets accepted, I intend to submit a patch for vpnc-scripts as well:
>
> https://github.com/bugfood/vpnc-scripts/commit/19b0357349f3cede6d93245d8373be4ef7239866

This patch seems to treat "split DNS domains" as a synonym for
"default DNS search domains."  I am not sure if this is the right
thing to do.  Split tunneling is intended to let you send traffic and
DNS lookups intended for (say) internal corporate hosts over the VPN,
while sending other all other traffic and DNS lookups to the public
internet.

In particular, you probably would not want to use split DNS in
conjunction with full tunnel routing.