Got confused with hotspot behavior

Ozelo · January 30, 2009, 3:47pm

Dunno exactly what Im doing wrong, but let me say something,

My hotspot setup is quiet simple. The hotspot interface has an address pool with public addresses. The DHCP server has an address pool with private adresses. But I dont get the following:

a- When a client has a valid ip config, but not belongs to the hotspot private network (e.g: client config = 169.254.123.123 hotspot network = 192.168.10.0/24), I can see 169.254 and the “to address” from the hotspot hosts with a public IP. Seems to be correct. If this client do authenticate, everything goes right.

b- When a client has a valid ip config and belongs to the hotspot private network (e.g: client config = 192.168.10.4 hotspot network = 192.168.10.0/24), I can see on both “address” and “to address” with the same private IP. Seems to be correct too. If this client do authenticate and receive a radius attribute framed-pool equal to that public ip pool, everything goes right. But, why this client does not grab a public IP from the pool if the radius attribute is removed?

c- When a client has a valid public ip config and belongs to the hotspot public network (e.g: client config = 189.9.9.9 hotspot public network = 189.9.9.0/25), I can see on both “address” and “to address” with the same public IP. Seems to be correct too. If this client do authenticate, everything goes right.

This behavior suggest that the DHCP server should give public adresses instead private ones, even if there is no active hotspot users. Then authenticated users just keep using it. The same as disabling the universal client (hotspot address pool=none), but with a waste of public IP resources.

Then the (b) behavior seems to be the better one. Only authenticated users grab a public IP from the pool by receiving the radius attribute “framed-pool”. What I dont get is why (a) behavior does not happen if I remove this radius attribute? I mean, that radius attribute is strict required if you want to save public IP resources? Otherwise, Without the radius attribute, client hosts will use public IP addresses even without authentication?

Please, give me some light. I cant see its idea clearly. I was thinking that only active (authenticated) hotspot users could have a public IP address, like on pppoe servers.

Thanks
Ozelo

mersudin · January 30, 2009, 3:57pm

do u understand that hotpot creates it’s own firewall and it can only be avodied if u set ip bonding to that mac and set it be bypassed and then your public pool can give public ip to that user.
if u done ip address assignemnt to corresponig interface and added gateway that u should have zero problem

Ozelo · January 30, 2009, 4:14pm

do u understand that hotpot creates it’s own firewall and it can only be avodied if u set ip bonding to that mac and set it be bypassed and then your public pool can give public ip to that user.
if u done ip address assignemnt to corresponig interface and added gateway that u should have zero problem

yes, I do. I have no problem on authentication or bypassing who does not need to. I do not understand why the only way to save public IP resources is using a radius attribute. Perhaps, I didnt asked the right question.

Ozelo · February 1, 2009, 9:58am

Guess I need to figure it out my self…

Ozelo · February 2, 2009, 10:10am

yet I still didn’t know how to give an IP for a hotspot user without a remote radius attribute “Framed-pool” only when this user do authenticate. I would like to give private IP via DHCP and then, nat 1:1 with public ones after user authentication WITHOUT a “Framed-pool” attribute and without local secrets. Couldn’t figure it out by my self yet, anyone? help?

SurferTim · February 2, 2009, 10:51am

I haven’t answered because I am not certain what you want. Your hotspot should issue IPs with DHCP. It is part of the setup. Do you want to bypass a computer or AP through the hotspot?

EDIT: Normis is correct below. A drawing may help.
Also, 169.254.123.123 is not a valid ip address. That is what Windows gives the interface now if a dhcp server does not respond.

normis · February 2, 2009, 10:52am

sometimes an image helps. maybe Ozelo could post a network drawing?

SurferTim · February 2, 2009, 11:22am

After reading your first post closely, I think you may be confused by the one-to-one nat the hotspot uses. If what I read is correct, all appears to be working as designed, except maybe your dhcp server is not set correctly. It should be issuing ips in the 192.168.10.x/24 range if the hotspot interface is 192.168.10.1/24.

If the client refuses a dhcp assignment (like a static assignment in the client, or dhcp from another source), the hotspot does a automatic one-to-one nat, so your client can log in, despite the ip challenge.

I almost forgot. The reason the 169.254.123.123 does not work is: Windows assigns no gateway, so it will not try any network addresses outside its ip range.

Ozelo · February 2, 2009, 5:53pm

Aye, I think I got it. It was the way we implemented the hotspot feature. I don’t think that a network draw is necessary at the moment because this is quiet a simple setup, but let me do some extra explanations:

Before the use of hotspot feature, our devices setup had only pppoe server with remote authentication with absolutely no IP settings on the AP interface. Then authenticated people grab a public IP issued via radius with a “framed-pool” attribute. Consider the following:

Public Network ----> (Public interface with public IP) ----> (pppoe server on the AP interface with no IP) ----> customers.

After some tries, we implemented the hotspot feature (private IPs but no masquerade, just NAT 1:1) together with the pppoe server:

Public Network ----> (Public interface with public IP) ----> (pppoe server and hotspot on the AP interface with private IPs) ----> customers.

Then, from a customer view point, pppoe connections could be done like before and customers starting to use the hotspot feature initially grab a private IP config from DHCP just to access the hotspot login page. On authenticating, these hotspot customers grab a public IP issued via radius with a “framed-pool” attribute and perform NAT 1:1. Everything was working great at this point. Note that both pppoe (“/ppp profile set 0 remote-address=none”) and hotspot (“/ip hotspot set 0 address-pool=none”) IP pool was locally set to “none”, just using its name via radius.

The problem started when we removed the “framed-pool” attribute from radius. The same pool name of public IP used for this radius attribute was locally set on both places, pppoe (“/ppp profile set 0 remote-address=my_public_ip_pool”) and hotspot (“/ip hotspot set 0 address-pool=my_public_ip_pool”).

Nothing changed for people who connects using pppoe, but not for the hotspot customers. So pppoe was OK, but not the hotspot and we just stopped using that radius attribute. Throubleshooting, we did the following successful tries before moving back to use “framed-pool”:

Moving all the private settings to a public one on the AP interface and DHCP works fine, but a waste of public IP resources. People who are on hotspot grab a public IP anyway; With NAT 1:1 even more waste of IP because they use two public IP(one from DHCP and one from NAT 1:1 from the same IP pool).
Removed DHCP server completely and kept the private IP config on the AP interface with hotspot. Works fine performing NAT 1:1 for hosts with a valid but different IP settings from that was set. Like very well explained above, windows machines and zero config hosts don’t, as expected. Gladly, only authenticated hotspot customers make use of one public IP address, but no use without DHCP.

Gratz to SurferTim, because now I got clearly enough that this is indeed a regular hotspot behavior. Im sorry then. Would be great if we could save public IP resources like it was when using the radius attribute, forcing hotspot customers with private addresses to grab a public one and perform NAT 1:1, even if its address belongs to the DHCP server.

Nowdays we can turn NAT 1:1 off by setting “/ip hotspot address-pool=none”. Is there any way to add a checkbox in future ROS versions, that force (when authenticating) hotspot users to grab a IP from this pool? I mean, whenever checked this box with a valid address-pool (“/ip hotspot address-pool”) setting, by login in, the hotspot customers grab an IP from that specified pool no matter what. Such feature sounds perfect, don’t you agree? Till then, we will keep using the radius attribute to save public IP resources on hotspot deployments.

Hope I could explain and sorry my bad english.
Thanks
Ozelo

ps: Awesome signature contents

Ask, and you shall receive