Maintained by: NLnet Labs

Filtered Redirect (captive portal)

Simon Wedge
Mon Feb 27 12:50:05 CET 2017


I can now shed some more light on the behaviour:
This is my test configuration:

access-control-view: [ip-range]/24 whitelist
...
local-zone: "." redirect
local-data: ". A [server-ip]"
...
view:
        name: "whitelist"
        local-zone: "google.co.uk" transparent
        view-first: yes
...

Test 1:
nslookup google.co.uk [server-ip]
Result 1:
Name:    google.co.uk.sant.ox.ac.uk        (that doesn't look right)
Address:  [server-ip]

Test 2:
nslookup www.sant.ox.ac.uk [server-ip]
Result 3:
Name:    www.sant.ox.ac.uk.sant.ox.ac.uk           (still not right)
Address:  [server-ip]

Test 3:
nslookup google.co.uk. [server-ip]
Result 2:
Name:    google.co.uk                                                    (works as expected)
Addresses:  2a00:1450:4009:801::2003
          172.217.23.3

Test 4:
nslookup www.sant.ox.ac.uk. [server-ip]
Result 4:
Name:    www.sant.ox.ac.uk                                       (works as expected)
Address:  [server-ip]

>From this I have come to the conclusion that when a global redirect is in place using "." it is unable to match any other "local-zone" without appending . onto the end of the initial DNS request.
I honestly don't know where to go from here, users won't be appending all of their DNS requests with . on the end of each request, and I need the redirect to work with the whitelist.

As previously mentioned not using redirect doesn't result in this behaviour, as refuse (for example) works without having to add . onto the end of the DNS request, is this a bug?

Simon.

From: Unbound-users [mailto:unbound-users-bounces at unbound.net] On Behalf Of Simon Wedge via Unbound-users
Sent: 27 February 2017 09:06
To: unbound-users at unbound.net
Subject: RE: Filtered Redirect (captive portal)

Apologies for following this up but does anyone have any suggestions on what I should need to do to get a redirect everything working with some exceptions?
It sounds like Unbound should be able to do this, but for the life of me I can't get it to work.

Simon.

From: Unbound-users [mailto:unbound-users-bounces at unbound.net] On Behalf Of Simon Wedge via Unbound-users
Sent: 21 February 2017 20:08
To: unbound-users at unbound.net<mailto:unbound-users at unbound.net>
Subject: Filtered Redirect (captive portal)

Hi All,

I am currently building a Network Access Control system, and in order to keep it "out of band" (via a layer 3 firewall), I would ideally like to use a DNS redirect to direct people to the NAC server from a registration VLAN.
I am having issues with doing a redirect with some exceptions (the registration VLAN needs access to the University Shibboleth servers and the IT registration pages which are outside the College network).

Now I realise that I am not the first person to try and do this, so I searched the mailing list for similar discussions.
https://www.unbound.net/pipermail/unbound-users/2010-April/001134.html
https://www.unbound.net/pipermail/unbound-users/2010-May/001171.html

Based on what I found (and read in the annotated unbound.conf file) I realised that something like this should work:

local-zone: "." redirect
local-data: ". A <NAC server ip>"
local-zone: "google.co.uk" transparent

This however doesn't seem to work as I would expect it to, as everything is redirected by the local-data to the NAC server ip.
(note: changing this to "refuse" rather than "redirect" works as expected, can connect to google.co.uk, get refused for everything else)

I thought this might be a version issue, as CentOS 7 is packaged with an older version (1.4.20??) and I know that in recent versions additional options were added for the zone types.

So I compiled 1.6.0 from source and experienced the same behaviour, even when attempting to use always_transparent , I tried all sorts of other iterations of options and none worked as I had hoped...
Noticing that I can find multiple references to the above example, has the behaviour of Unbound changed?

If so how do I accomplish the above, I would expect the "always_transparent" would have been the answer if the local-data was the cause of the behaviour:
"always_transparent      Like  transparent,  but  ignores local data and resolves normally."

But this still doesn't work as expected when using a redirect.

Many Thanks,

Simon Wedge
St Antony's College
University of Oxford
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170227/7d7db89d/attachment.html>