How can you allow DNS traffic, or any other traffic, to pass through the
m0n0wall before the user authenticates on the portal page?
From: Craig FALCONER <cfalconer at avonside dot school dot nz>
Date: Thu, 31 Aug 2006 21:19:46 -0400
To: Mark Opert <marko at clinedavis dot com>
Cc: <m0n0wall at lists dot m0n0 dot ch>
Conversation: [m0n0wall] DNS problems with Apple and AD
Subject: RE: [m0n0wall] DNS problems with Apple and AD
I'd suggest that you allow unauthenticated traffic to the DNS server on the
DNS port (53 UDP I think)
It's a small security risk.
You could also configure your laptops to use the m0n0wall box as primary DNS
From: Mark Opert [mailto:marko at clinedavis dot com]
Sent: Friday, 1 September 2006 5:01 a.m.
To: m0n0wall at lists dot m0n0 dot ch
Subject: [m0n0wall] DNS problems with Apple and AD
I am testing a m0n0wall captive portal with our corporate wireless network
and have found a problem for us. With our large number Apple laptops that
are bound to Active Directory, the laptops become incapacitated when they
boot up from a DNS issue.
When the Apple systems boot they perform a DNS lookup for the AD servers.
M0n0wall blocks all the DNS lookups until it is an authorized machine. So
the Apple system hangs by either waiting for a response from an AD server,
if the m0nowall is a DNS relay, or the Apple system freezes attempting to
contact a DNS server that m0n0wall is blocking.
This occurs at boot for all systems and logout for any system that has not
authorized from the m0nowall portal page.
What the Apple systems need it when the system boots and makes a request for
ad.xxx.com to respond with a failure (no answer does not work, it must be a
failure), and once the laptop makes a portal login to get a different DNS
server that will then respond with the proper addresses.
Has anyone have a suggestion?