Maintained by: NLnet Labs

Filtered Redirect (captive portal)

Simon Wedge
Tue Feb 21 21:08:10 CET 2017


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/20170221/954f47dc/attachment.html>