IMHO there is no need for any sort of DNS redirection after user
authentication has taken place.
It may be hazardous even before user authentication has taken place.
Even given a very low TTL, client resolvers may cache answers returned
during that initial authentication.
We of course redirect UDP/TCP 53 to one of our servers along with 80
(http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any
authentication has occurred, but once this is completed the only reason
any guest would use the local DNS server is if they were assigned a DHCP
address.
Which, presumably, many/most of them are. Supplying a functional DNS
server shouldn't be that difficult, but real world experience shows just
how well some operators run these services.
As far as our Routerboard/Mikrotik setup works, it'll masquerade for any
non standard IP addresses that appear on the network (guests with static
ip's assigned, corporate laptops etc) but once again after the
authentication stage anything is allowed to pass unhindered.
The only redirection that is used after authentication is for port 25 as
90% of user trying to send mail out via port 25 have no idea how to
change their mail server, let alone why they might need to.
It can be an issue as some systems use authentication on port 25.
Sounds like an opportunity for a custom proxy. Clients that can
successfully authenticate to an external mailserver on 25 are probably
by definition nonproblematic. The remainder probably deserve to get
jammed through an aggressive spam, virus, and other-crap filter, with
in-line notification of rejections. You can do some other sanity stuff
like counting the number of hosts contacted by a client; anything in
excess of a small number would seem to be a good indicator to stop.
This really should be a DHCP option which points to the authentification
server using ip addresses. This should be return to clients even
if they don't request it. Web browers could have a hot-spot button that
retrieves this option then connects using the value returned.
This really should be a DHCP option which points to the authentification
server using ip addresses. This should be return to clients even
if they don't request it. Web browers could have a hot-spot button that
retrieves this option then connects using the value returned.
Unfortunately, that's not how DHCP works. If you send the client a
DHCP option which the client has not requested, you have no idea if
the client will use (or for that matter even *understand*) the option.
Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected.
Until such time it's simply unworkable.
That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops.
It can still parse and skip it from the the DHCP response as every
option contains its own length. Initially clients will ignore it
but over time it will be supported on the client side. This is a
much better way than intercepting DNS queries and returning respones
that will just be ignored by validating and iterative resolvers.
Something like http://1.2.3.4/terms.html or http://[2001::1]/terms.html
doesn't require that everthing be intercepted. Just block until
acceptance.
Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected.
Until such time it's simply unworkable.
That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops.
And it just breaks for those of us who actually expect "internet access" to mean
access to the internet, not just the web.
I make a habbit of calling support and pushing the issue hard through multiple
layers until I finally get a management denial, then, demand refunds of my
connectivity charges every time I encounter this at a hotel.
I figure that the reason you guys deploy what "just works" as you put it is because
it lowers your support costs, so, I do what I can to increase the support costs of
delivering a broken internet.
Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected.
Until such time it's simply unworkable.
That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops.
And it just breaks for those of us who actually expect "internet access" to mean
access to the internet, not just the web.
I never said that the *just works* method stopped users from being able to use the internet. In fact catching users with bad IP address settings works just as well as sending them a DHCP address.
I make a habbit of calling support and pushing the issue hard through multiple
layers until I finally get a management denial, then, demand refunds of my
connectivity charges every time I encounter this at a hotel.
I figure that the reason you guys deploy what "just works" as you put it is because
it lowers your support costs, so, I do what I can to increase the support costs of
delivering a broken internet.
We're in no way in the business of providing half-baked services and likewise, I call up support for other providers if I end up with just web access.
Sounds like a great idea in theory but would require OS support or a dual-hotspot setup that provided for both options until support was expected.
Until such time it's simply unworkable.
That and as mentioned in my previous post, the setup we have *just works* for users who don't have the permissions to change off of a static IP and use DHCP on their laptops.
And it just breaks for those of us who actually expect "internet access" to mean
access to the internet, not just the web.
I never said that the *just works* method stopped users from being able to use the internet. In fact catching users with bad IP address settings works just as well as sending them a DHCP address.
I expect my connections to my mail server to actually reach my mail server. I use TLS
and SMTP AUTH as well as IMAP/SSL. Many of the "just works" settings in question
break these things badly.
Stop doing man in the middle attacks on my mail, or, expect me to be a support headache.
It's just that simple.
I make a habbit of calling support and pushing the issue hard through multiple
layers until I finally get a management denial, then, demand refunds of my
connectivity charges every time I encounter this at a hotel.
I figure that the reason you guys deploy what "just works" as you put it is because
it lowers your support costs, so, I do what I can to increase the support costs of
delivering a broken internet.
We're in no way in the business of providing half-baked services and likewise, I call up support for other providers if I end up with just web access.
Good... As long as you're not MITM my stuff, then, I won't be calling your support people.
Perhaps I misunderstood your explanation of what you do to port 25 traffic that "just works".
I expect my connections to my mail server to actually reach my mail
server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just
works" settings in question break these things badly.
One of my customers has an appliance for his WLAN guest access access
which filters out AAAA records.
why do you presume the DNS service is in the same path as the
TLS/SSL?
a loose reading of these posts might give the gullible the impression
that the IP datagrams between the source and the target pass through
the DNS server... which we -KNOW- is false.
I expect my connections to my mail server to actually reach my mail server. I use TLS and SMTP AUTH as well as IMAP/SSL. Many of the "just works" settings in question break these things badly.
One of my customers has an appliance for his WLAN guest access access
which filters out AAAA records.
That, unfortunately, is not uncommon. Actually, it's one of the _less_
broken systems I've seen, since IPv4 presumably keeps working.
One major vendor of hotel guestnet equipment returns an A record for
0.0.0.1 if you do an ANY or AAAA query for any hostname--even ones that
don't exist. At least with WinXP, you have to disable IPv6 just to get
IPv4 to work! Worse, their tech support sees nothing wrong with this;
if you disagree, all they'll do is offer a refund. Unfortunately, "take
your money elsewhere" doesn't work when you've already paid for the
hotel room--and they know it.
I've actually extracted significant rebates from Hotels where their internet
was provably broken, and, their third-party provider would not resolve
the issue. More than just a refund of the IP fees. In one case, 1/2 the
cost of my multi-night stay.
