Captive Portal - Bypass Address/Subnet not working

[tee4cute]

Hi,

I'm facing the same issue with this thread:
https://forum.pfsense.org/index.php?topic=123360.0

I've just restarted the system in this morning and this issue suddenly appeared without changing any configs or system upgrades.

This is my system envs:
OPNsense 17.1.8-amd64
FreeBSD 11.0-RELEASE-p10
OpenSSL 1.0.2l 25 May 2017

I've tried to delete and re-create all CP zones again but it not worked. The thread I mentioned above was resolved by upgrading to the new system version. But, for mine, it seems that I'm having the latest release. So, before trying to re-install the entire machine, I may open the issue here to let you guys help me to investigate that this is a bug or not?

Cheers!

[tee4cute]

Oh, I forgot to tell you that, in my case, I want to bypass the CP by Address/Subnet, not MAC. But the referencing thread I mentioned above is about bypassing by MAC.

Nevertheless, I've tried to use MAC bypassing too, but have no luck! (still have the same issue/behavior as using Address/Subnet). So, I assume that both two issues are closely related and use this thread as the reference.

Thanks!

[AdSchellevis]

We're not using any of the pfSense code for captive portal, it's rebuild from scratch, so it's quite unlikely a related issue.

If you share more details about your setup (like some screenshots), maybe we can point you in a direction.

[tee4cute]

Ok, first of all, I'm sorry for giving you useless information by referring to pfSense (all I need is to give you a case that is most likely the same as mine).

Here are my settings / screenshots:

a) Interfaces: I've 3 WANs (load-balancing). All other interfaces are LANs.

b) Gateway Group:

c) Firewall Rules: I only upload the screenshots for interfaces containing manually input rules. All other interfaces having auto generated rules (i.e. from NAT) are not presented here.

Floating Rules

ABSOLUTE interface

AWII interface

GUEST interface

d) NAT:

e) DHCP: For all LAN interfaces, the subnet 10.x.0.0/24 and 10.x.2.x/24 are reserved for static DHCP, and all automatic DHCP pools are set in the range of 10.x.1.0/24 (10.x.1.1 - 10.x.1.254)

f) CP Zones: The screenshot captured here showing that only GUEST interface is enabled since I've to disable all other interfaces to make the system working for now. But, I'm encountering this issue in all interfaces.

g) Zone Settings: You can see that I already put static subnets in Allowed Addresses input field.

h) Client IP: I've already checked that my laptop having static DHCP address (10.x.2.x).

Work around & system behavior I found:

1. If I use all settings the same as presented above, my laptop will not be able to login into CP. It shows "authentication failed". But other computers that are not in static DHCP (not in Allowed Addresses) will be able to login normally.

2. If I remove all Allowed Addresses in CP and try to login with my laptop again with the same IP address (10.x.2.x), I'll be able to login into CP normally.

3. I tried putting my laptop IP (10.x.x.x/32) into Allowed Addresses. The behavior is the same as (1).

4. One more weird thing (I know that I should open this issue in another thread. But, I think that it may relate to this issue), you can see from screenshot (f) that I've to add 2 DUMMY CPs (zone id: 0, 1) into the list first. I don't know what's wrong with that first two zones. If I set CP on any interfaces in that two zones, I'll always get "authentication failed" even Allowed Addresses is set or not.

Hope this help!

[tee4cute]

To make a thing clearer, the behavior I'm expecting, which the system behaved 2 days ago before last restart, I might get throught the internet without logging in into CP if the client is in static DHCP subnet. But, the situation I'm facing here is that I'm still prompted by the login screen and cannot login into CP as described in (1).

[AdSchellevis]

Normally it should allow addresses coming from 10.254.0.x and 10.254.2.x on interface "guest", it's probably best to test step by step. First setup your Guest network with a simple firewall rule
allowing all (disable the floating rule and add one rule allowing all using the standard gateway) and check if the CP still redirects.

If that's the case, we might inspect the underlaying rules, for that we need the output of:
ipfw show
(in a console)

[tee4cute]

I followed the instructions you gave above. But, I had no luck :(

First: disable all floating rules. Note: I've to let the last rule forwarding other connections to "LB_ALL" gateway group still be enabled since the system is up and running and there are some users still using the internet for their works. But, I already unchecked the "Apply the action immediately on match".

Second: disable all GUEST rules and add a simple forward all to default gateway rule into GUEST.

I also attached the ipfw output as requested in this comment: ipfw_output.txt

Thanks!

[AdSchellevis]

It's better to test without the gateway group first, to avoid other interferences, but let's check the contents of the ipfw list first:

ipfw table all list

To be sure, check the ip address of the client your trying to connect with and please report that back too.

[tee4cute]

Hi,

I've disabled all manually-input rules in all interfaces and tested without gateway group (use default gateway instead). And, also rechecked the client's ip address as you suggested (my client's ip is 10.254.2.252).

The Allowed Addresses in GUEST interface is currently set.

I'm still redirected to CP login page ...

This is ipfw table all list output:

ipfw table all list.txt

Andipfw show output:
(some configs changed from last time since since I use default gateway instead.)

ipfw show.txt

Cheers!

[AdSchellevis]

Ok, that's odd, this is currently in your list:

--- table(5), set(0) ---
10.254.1.16/32 0
10.254.1.19/32 0
10.254.2.4/32 0

Have you applied your settings?

[tee4cute]

These are the steps I perform the test:
(I repeat all these steps again to ensure that I didn't miss anything)

• You can see that I change "LB_ALL" gateway group to "default" one.

• All custom rules in GUEST (and all interfaces) are disabled:

• Click on the "Apply Changes" button. This message will be shown:

• I re-checked that the "Allowed Addresses" in GUEST CP zone is set. Then click "Save Changes" and click "Apply" button again in CP Administration page.

• Connect wifi with my laptop and it redirect me to CP login page. This is may laptop IP:

• SSH to OPNSense machine and execute ipfw table all list cmd:

root@cdg:~ # ipfw table all list
--- table(0), set(0) ---
--- table(1), set(0) ---
--- table(2), set(0) ---
10.1.1.19/32 0
10.1.1.29/32 0
10.1.1.64/32 0
10.1.1.65/32 0
10.1.1.97/32 0
10.1.1.117/32 0
10.1.1.120/32 0
10.1.2.4/32 0
--- table(3), set(0) ---
10.2.1.30/32 0
10.2.1.41/32 0
--- table(4), set(0) ---
--- table(5), set(0) ---
10.254.1.16/32 0
10.254.1.19/32 0
10.254.2.4/32 0
--- table(6), set(0) ---

It seems to be the same...

I don't know much about how OPNSense interact with ipfw. So, I really have no idea how odd it is (forgive me for that). Please give me the next step to test and let me help you to investigate on this.

P.S. Is it a good idea to let you ssh into my OPNSense machine via OpenVPN to investigate on this issue?

Thanks :)

[AdSchellevis]

can you check if the captive portal background process is running?

ps -fax | grep cp-background-process.py

If not, can you try to run the following and see if it crashes?

/usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py run

[tee4cute]

It seems cp-background-process.py is not currently running.

root@cdg:~ # ps -fax | grep cp-background-process.py
44317  0  S+       0:00.00 grep cp-background-process.py
root@cdg:~ # /usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py run
Traceback (most recent call last):
  File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py", line 213, in main
    bgprocess.db.update_accounting_info(bgprocess.ipfw.list_accounting_info())
  File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/lib/db.py", line 271, in update_accounting_info
    for row in cur.fetchall():
DatabaseError: database disk image is malformed

Feels like getting close to the solution :). How could I do next?

[tee4cute]

Okay AdSchellevis,

I've tried this:

1. cd /var/captiveportal/

2. mv captiveportal.sqlite captiveportal.sqlite.b
   I guess that CP will automatically create sqlite db file if is not found.

3. /usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py
   At this point, I found that the captiveportal.sqlite is automatically created.

4. /usr/local/etc/rc.d/captiveportal stop
   Stop the service to ensure that it is cleanly restarted.

5. /usr/local/etc/rc.d/captiveportal start
   Start service again.

6. ipfw table all list

--- table(5), set(0) ---
10.254.0.0/24 0
10.254.2.0/24 0

It seems right! I tried to connect to GUEST network. No CP login screen showed anymore :)

All steps above I tried to figure it out based on my guess with the source code cp-background-process.py & */rc.d/captiveportal. So, I don't know that it is the right solution or not?

Even though my issue has been resolved, I'm willing to help you digging the cause of CP's sqlite db file corruption (if you want to).

Please let me know.

Really appreciate for your great support!

[tee4cute]

Just another feedback, for the weird thing I mentioned above:

One more weird thing (I know that I should open this issue in another thread. But, I think that it may relate to this issue), you can see from screenshot (f) that I've to add 2 DUMMY CPs (zone id: 0, 1) into the list first. I don't know what's wrong with that first two zones. If I set CP on any interfaces in that two zones, I'll always get "authentication failed" even Allowed Addresses is set or not.

This problem is completely resolved too. I think that I'm having the issue with sqlite db file a very long time ago since I had been with this weird thing a long time ago before all CP functionalities are gone.

Cheers!

[AdSchellevis]

@tee4cute it doesn't happen very often (usually a result of a system crash), we probably should check the database when starting and remove the database automatically if it's beyond repair.