Hello David,
> All works, except when people have a static DNS setting set in their network
> settings that overrides the DHCP DNS allocation - even though the gateway on
> registration is the packetfence server, they'll never get to see it, because
> DNS lookup fails, and the browser quits trying.
> Safari on OSX will say something like "You are not connected to the
> internet", and at that point, guests will stop trying to connect and assume
> something is wrong with the network.
That is an “issue” (or more like, a behavior) that we (at least, I) see here
and there.
> The solution (I think) is to add a couple of iptables rules to the
> /usr/local/pf/conf/iptables.conf in the nat section (ish, this is command
> line, the conf file needs to have the iptables -t nat bit removed)
> eth2 is our isolation net, and eth3 is our registration net.
>
> iptables -t nat -A PREROUTING -i eth2 -p udp --dport 53 -j DNAT --to
> 10.1.1.245 #isolation net, interface has address 10.1.1.245
> iptables -t nat -A PREROUTING -i eth3 -p udp --dport 53 -j DNAT --to
> 10.2.1.245 #registration net, interface has address 10.2.1.245
>
> This means that queries that originate from a client machine on the
> registration network get redirected to be answered locally, and then sent
> back out to the client.
>
> I've successfully tested this on my macbook with google's dns (8.8.8.8)
> statically set. Tcpdump on my the macbook suggests that "Google" is answering
> the queries, and redirecting to the captive portal.
That fix is working when working with out-of-band and layer 2 networks. That’s
basically what we do when using inline (DNAT the DNS).
> The stumbling block might be DNSSEC, perhaps?
Correct, that may (will) break DNSSEC, but this is not widely used AFAIK…
You may also introduce some DNS caching issues (at least, with Chrome) but
nothing big.
> There is technically TCP for DNS, but I don't think its in wide use.
TCP is used in DNS with a “large” request / answer… it is not “a choice” of
using TCP or not so you may want to consider it :)
Cheers!
dw.
—
Derek Wuelfrath
[email protected] :: +1.514.447.4918 (x110) :: +1.866.353.6153 (x110)
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
> On Apr 17, 2016, at 22:37, David Murrell <[email protected]> wrote:
>
> Hi,
>
> This is less a problem, and more a possible solution to a silent issue, but I
> wouldn't mind some feedback if someone thinks there's a problem lurking
> somewhere.
>
> We run a guest network with sponsor authentication in out of band mode.
> Guests use a registration network to connect to the packetfence server.
>
> All works, except when people have a static DNS setting set in their network
> settings that overrides the DHCP DNS allocation - even though the gateway on
> registration is the packetfence server, they'll never get to see it, because
> DNS lookup fails, and the browser quits trying.
> Safari on OSX will say something like "You are not connected to the
> internet", and at that point, guests will stop trying to connect and assume
> something is wrong with the network.
>
> The solution (I think) is to add a couple of iptables rules to the
> /usr/local/pf/conf/iptables.conf in the nat section (ish, this is command
> line, the conf file needs to have the iptables -t nat bit removed)
> eth2 is our isolation net, and eth3 is our registration net.
>
> iptables -t nat -A PREROUTING -i eth2 -p udp --dport 53 -j DNAT --to
> 10.1.1.245 #isolation net, interface has address 10.1.1.245
> iptables -t nat -A PREROUTING -i eth3 -p udp --dport 53 -j DNAT --to
> 10.2.1.245 #registration net, interface has address 10.2.1.245
>
> This means that queries that originate from a client machine on the
> registration network get redirected to be answered locally, and then sent
> back out to the client.
>
> I've successfully tested this on my macbook with google's dns (8.8.8.8)
> statically set. Tcpdump on my the macbook suggests that "Google" is answering
> the queries, and redirecting to the captive portal.
>
> The stumbling block might be DNSSEC, perhaps?
>
> Anything I've missed? There is technically TCP for DNS, but I don't think its
> in wide use.
>
> Cheers,
> David Murrell
>
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
> PacketFence-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
