Captive Portal

hi there, I have an instance of monowall in a hotel where for years has been one of the rare install&forget case. Now I had to change hardware and monowall version but sometime, although the version is newer, CP works correctly for some week after wich everybody gets inside the network directly with no need of auth. it's pretty strange. when  i reboot the machine it starts working correctly again.

1.32  built on Sat Apr 17 21:01:56 CEST 2010
Platform    PC Engines ALIX
 
best regards and huge thanx for the excellent work.

Sebastiano

The output of http://m0n0wall/status.php (taken when the problem is actually occurring, i.e. when users get through the CP without authentication) would be very helpful in diagnosing this issue.

Also, you may want to upgrade to 1.33 in any case.

The output of http://m0n0wall/status.php (taken when the problem is actually occurring, i.e. when users get through the CP without authentication) would be very helpful in diagnosing this issue.

Also, you may want to upgrade to 1.33 in any case.

OK. I will upgrade as soon as I'll see the issue again but first will grab the status for you

cheers

Sebastiano

Is this good for you? Just rename it to .rar. the original log is 360 KB and can't be uploaded and the .rar is not accepted so.. . now a guest got inside with no need to login. See the attachment?
If you need any othe info I will keep the status like now for another 2 houres for you. do not hesitate to contact me


Sebastiano

Is this good for you? Just rename it to .rar. the original log is 360 KB and can't be uploaded and the .rar is not accepted so.. . now a guest got inside with no need to login. See the attachment?
If you need any othe info I will keep the status like now for another 2 houres for you. do not hesitate to contact me


Sebastiano

may I reboot now?

may I reboot now?

Yes, of course.

I think I've found the problem: you don't have an idle timeout set in your captive portal configuration. That means when clients disconnect from your Wi-Fi network (without logging out through the captive portal), their IP address remains online in the captive portal. Later somebody else gets the same IP address and can use it to get online.

What you should do is the following:

1. Return sensible Session-Timeout values from your RADIUS server. Most admins don't allow sessions to go on for more than 7 days or so, even if the user's account is actually valid for more than that.

*and*

2. Reduce the idle timeout to one hour (since your DHCP lease time is 2 hours).

Done. Let's see what happen now. I will keep you in touch for this.
Thank's a lot for the time you spend for all this.

regards
Sebastiano

may I reboot now?

Yes, of course.

I think I've found the problem: you don't have an idle timeout set in your captive portal configuration. That means when clients disconnect from your Wi-Fi network (without logging out through the captive portal), their IP address remains online in the captive portal. Later somebody else gets the same IP address and can use it to get online.

What you should do is the following:

1. Return sensible Session-Timeout values from your RADIUS server. Most admins don't allow sessions to go on for more than 7 days or so, even if the user's account is actually valid for more than that.

*and*

2. Reduce the idle timeout to one hour (since your DHCP lease time is 2 hours).