Captive Portal

Hi,

i have set up the captive portal (m0n0 1.3b14) with a WLAN Access-point. At first i had WPA turned on at the AP for testing and everything worked fine (tested 5 different clients), even on a Nokia S60 mobile phone. Only one client (IE6 on Dell WinXP notebook) did not get to the login-page, even when entered manually.

Then i turned off the WPA encryption, but the client still doesnt get to the login page. It does get connectet to the WLAN and assinged an IP from DHCP on mono. Its pingable via mono-interface, but on the client i cannot access anything, even if i enter the mono-interface IP (which is accessible normaly).

The client usually works in any WLAN Hotspot so far and has also no problems with normal WPA encrypted personal WLANs. I double checked network settings, firewall and such, but everything seems to be ok.

Also, since i turned off the WPA encryption, the S60 mobile doesnt connect any more ...? The other clients have no problem and work correctly.

Do you have any clue were to check further? Any help appreciated.

Try this, type this manually into the web browser http://192.168.XX.XX/ where m0n0wall is the IP address and put a :8000 after it, so you get something like http://192.168.1.1:8000/

That's a direct link to the login page, port and all. If you can't get this manually, then some other problems exist that need to be resolved before you'll be able to resolve the captive portal issues.

Hi,

I got  the same problem.  When I connect to the WLAN used with captive Portal, my browser is not redirected to the Portal Authenication Page (I want to use Vouchers).

If I type monowall_ip:8000 I get connected to the portal page.

Got any Ideas?

Regards
Georg

Hi,

I got  the same problem.  When I connect to the WLAN used with captive Portal, my browser is not redirected to the Portal Authenication Page (I want to use Vouchers).

If I type monowall_ip:8000 I get connected to the portal page.

Got any Ideas?

Regards
Georg

First try different browsers (I've heard the IE safe browsing mode breaks captive portal) then if Firefox/Chrome/IE/Safari/Opera/etc don't work, look at the firewall being used as some of them also break captive portal by disabling higher port number HTTP packets (McAfee, Norton, etc.)

[Whenever the captive portal stops working, turning it off an then on again makes it start working.]

I have been having similar problems.  Here are the details:

I am using m0n0wall version 1.236. (Newest)
Captive portal is turned on.
RADIUS authentication is used against a Windows IAS server.
DHCP leases are handed out by a Windows domain controller.
The problems reported occur in all browsers.

Our m0n0wall is used as a firewall to separate our wired from our wireless network.  In an ideal situation, a user connects to the wireless network, they open their browser and are redirected to the captive portal page where they enter their credentials and are allowed to continue on to the WAN interface.  

Occasionally, the captive portal will stop catching and redirecting web traffic.  When this happens, clients are connected to the wireless network and can access any resource inside of that network.  All 10.0.*.* addresses are ping-able, including the m0n0wall itself.  Going to http://10.0.0.1:8000 does bring up the captive portal page, but if you enter your credentials, you still aren't listed as having logged in on the captive portal status page of the m0n0wall web GUI and you still can't get web traffic.  

However, whenever this happens, if you open the m0n0 web GUI, disable the captive portal, click save, re-enable the captive portal and click save again, and then open your web browser, it begins capturing and redirecting web traffic to the captive portal.

Put another way: Whenever the captive portal stops working, turning it off an then on again makes it start working.

[Whenever the captive portal stops working, turning it off an then on again makes it start working.]

I have been having similar problems.  Here are the details:

I am using m0n0wall version 1.236. (Newest)
Captive portal is turned on.
RADIUS authentication is used against a Windows IAS server.
DHCP leases are handed out by a Windows domain controller.
The problems reported occur in all browsers.

Our m0n0wall is used as a firewall to separate our wired from our wireless network.  In an ideal situation, a user connects to the wireless network, they open their browser and are redirected to the captive portal page where they enter their credentials and are allowed to continue on to the WAN interface.  

Occasionally, the captive portal will stop catching and redirecting web traffic.  When this happens, clients are connected to the wireless network and can access any resource inside of that network.  All 10.0.*.* addresses are ping-able, including the m0n0wall itself.  Going to http://10.0.0.1:8000 does bring up the captive portal page, but if you enter your credentials, you still aren't listed as having logged in on the captive portal status page of the m0n0wall web GUI and you still can't get web traffic.  

However, whenever this happens, if you open the m0n0 web GUI, disable the captive portal, click save, re-enable the captive portal and click save again, and then open your web browser, it begins capturing and redirecting web traffic to the captive portal.

Put another way: Whenever the captive portal stops working, turning it off an then on again makes it start working.

Well, it sounds like the captive portal was crashing then, doing the restart fixes it. I can't say I've seen this problem. My captive portal will have hundreds of days of uptime without any issues. I use captive portal to run an ISP where hundreds of people are logging in daily to use the Internet. The only time I ever need to restart captive portal is when making changes to traffic shaping rules. If you change the traffic shaping rules while captive portal is running, it locks up captive portal. You have to restart it. The easiest way to restart captive portal is to simple click the save button (don't need to disable/re-enable for example) it will do it for you auto-magically.

Hope this info helps. 

Well, it sounds like the captive portal was crashing then, doing the restart fixes it. I can't say I've seen this problem. My captive portal will have hundreds of days of uptime without any issues. I use captive portal to run an ISP where hundreds of people are logging in daily to use the Internet. The only time I ever need to restart captive portal is when making changes to traffic shaping rules. If you change the traffic shaping rules while captive portal is running, it locks up captive portal. You have to restart it. The easiest way to restart captive portal is to simple click the save button (don't need to disable/re-enable for example) it will do it for you auto-magically.

Hope this info helps. 

I will definitely try just clicking the "save" button; that would definitely save me a little bit of time, but I'd still be interested in knowing why CP is crashing. 

I will definitely try just clicking the "save" button; that would definitely save me a little bit of time, but I'd still be interested in knowing why CP is crashing. 

Are you using the built-in user manager for Capitve Portal or chaining off a radius server?

Are you using the built-in user manager for Capitve Portal or chaining off a radius server?

I am using the built-in Captive Portal - the Radius server is to validate credentials against the domain.

Are you using the built-in user manager for Capitve Portal or chaining off a radius server?

I am using the built-in Captive Portal - the Radius server is to validate credentials against the domain.

I would report as a possible bug then but before you do... I'm using the stable release version and you are using the beta. It's possible you've stumbled upon a bug in the captive portal for the older beta version.

Would it be possible to try this on the 1.2X stable version or the latest beta 1.3b18 version?

According to this page:

http://m0n0.ch/wall/downloads.php

Version 1.236 is the latest stable release, and it is not a beta version.  Am I mistaken?

Sorry for the late reply.  I only get on the forum when I think about it...  Remember that if a question is stuck in the forum, that you can try the mailing list as well...


Anyway, there are a few problems that can kill captive portal from a user point of view.

First is an alternative DNS like openDNS.  You can not lookup the web page, so you never request it, so you never redirect.  Pointing them to something like http://4.2.2.2 (which is a cacheing DNS and no web server) will trigger a redirect in that case.

Next is browsing protection, like McAfee site advisor, or others...  It tries to check to see if the link is safe, but can not get out, so it never lets you make the request, and you never redirect.  In SOME cases, a direct link to http://192.168.1.1:8000 will overcome this.  In others, turning off the virus scanner can do it.

Last, there is a bug that can hang CP.  Jonathan and I worked on it a LOT for quite a while.  It got better, but occasionally you can still get a hang.  I have over 100 firewalls in production, and I get about 2 a year.

I hope this helps.

First is an alternative DNS like openDNS.  You can not lookup the web page, so you never request it, so you never redirect.  Pointing them to something like http://4.2.2.2 (which is a cacheing DNS and no web server) will trigger a redirect in that case.

I think the issue might be related to this.  I changed the DHCP server from my Windows Domain Controller to the m0n0wall itself and have not had a problem in a couple days.  I would prefer to put it back on the domain controller for ease of management, but if it means not having a buggy captive portal I'll work around it.

I'm not sure I understand precisely what you are saying though... Are you saying that only alternatives like openDNS will cause this problem?  How would that change with any DNS server, since the principle behind captive portal is that it's never requested in the first place?  As I understand it, the firewall detects HTTP traffic, intercepts it and responds with a 302 error code and redirects the page to an IP.  Since it uses an IP, DNS would be irrelevant, correct?

Also, who are we pointing to http://4.2.2.2?  The clients?  Are you saying that instead of attempting to go to something like http://google.com before reaching the captive portal, they should go to http://4.2.2.2?  How exactly would this help to solve the problem?  Or are you saying that DHCP clients should to use an external DNS server like 4.2.2.2?  I've been using 10.0.0.1 (the m0n0 firewall address) as the DNS server.  Should I not use m0n0wall as the DNS server for that network on the LAN interface?

You are reading way to much into my answer, so let me back up. 

You can not traverse the m0n0wall until you authenticate the captive portal.  You will get get the login page until you make a http get that we can redirect.  If you are trying to hit a DNS on the far side of the m0n0wall to resolve the host, it will fail without every performing an http get.  This is why requesting http://80.254.71.228 will help, as it never needs to look up the IP address.  It doesn't even need to be real, just on another subnet so captive portal can grab it.  If you DNS is on the same subnet, there is no problem.  DHCP makes no difference at all.

Clear as muddy water?

Haha, yes, that makes much more sense.  In that case, I don't think that would have been the source of our issues, as the DNS server was inside of the local network.  Thank you!