[ABANDONED] Having a weird issue with primarily UDP traffic

[AdSchellevis]

I hope I'm still on time, time difference always is a challenge.

Any chance the ip addresses changed in the mean time? maybe something goes wrong with the arp sync...

Could you try to reload the captive portal and add the full range in one of the tables to see what happens then?

you can do that with :

Code: [Select]

ipfw table 9 add 10.24.72.2/24


and the try again, make sure the manual rule is gone (the reload should do that), because that opens up all.

[ledoktre]

Greetings,

I wonder what the chance is I'll find you online right now.  I'd really like to get this figured out.  Yeah, I did miss you last night.  I waited around for a while and just couldn't hold my eyes open any longer, sorry.

So in answer to your questions-

1. IP address changed in the mean time?  I am not sure which address you are referring to, but all the important stuff is setup either as sticky dynamic or static (phone, server, desktop I tested from, etc).

2.  Could you try to reload the captive portal and add the full range in one of the tables to see what happens then?  Yeah, I'll give that a try now.  Actually funny that you are mentioning the captive portal.  I found that this morning the captive portal was not obeying the whitelisted mac and ip addresses.  My users had to login with their usernames- very odd.

3.  Manual rule?  Ive rebooted a few times since then and my phone quit so I assumed that rule should be cone?  UPDATE- that rule was still there after reboots.  I ended up deleting it manually..

I am going to go ahead and probably reboot the router, try to output its config, try to figure out some of the rules for myself.  I'll look for that one rule you referred to (3) above too and try that code you wanted me to try.

Thanks- will post back soon.

[ledoktre]

Ok, so a couple things.

1.  I just figured out that you are one of the top dawgs.  Cool to be conversing with someone so close.  Thanks for helping me.

2.  I read somewhere that pfSense had some issue with using mac addresses (which I would prefer for security purposes) in their captive portal, so I moved all mine over to static dhcp leases and put them on the captive portal whitelist.  All good so far.  Only problem is, NOTHING can surf.

So I look at each table (I thought I had previously figured out table 7 was for CP logged in users, table 9 was those on a IP whitelist and table 11 was those on a mac whitelist).  7 was there as I had 2 users logged in by username.  But 9 and 11 were both empty (and no net connectivity on anything on the inside except for those logged in with username).  How could that be?  The IP list had a lot of them in there.

3.  I added the line for 10.24.72.0/24 like you'd mentioned and I started seeing connectivity again.  I haven't tried testing the original core problem yet, but what would cause the GUI to be correct but ipfw to NOT be correct (as in completely empty table 9)?

Thanks,

[AdSchellevis]

Your welcome 

The captive portal feature is scheduled for a full replacement in the next major version 16.1,  the version pfSense had relied very heavily on all kinds of non standard kernel patches we didn't want in there.
We had to do something for this version to keep CP working without breaking too much, so our implementation is already very different then the one in pfSense.

You where right with your assessment on the tables, but for future reference I will try to clarify all a bit more.

Let me first try to explain where the tables are used for in addition to what you already found out, hopefully we could eventually find your issue or find ourselves a way around them.

*   The first group:  authenticated users
In your case table 7, if there are more zone's the next will be 13 ( a gap of 6 for every zone).
When a user isn't authenticated yet and tries to connect, it will be forwarded to the login page via the forward rule.
( fwd 127.0.0.1,8002 tcp from any to any dst-port 80 in via em0 )
Which is serviced by an instance of "lighttpd".

*   The second group: authenticated hosts
In your case table 9, the next zone will use the same offset of six.
A listing of this group should be an exact copy of the "Allowed IP addresses" 
It's odd that this is empty in your last enquiry, we will have to look at this. (I will give some hints later on).

*   The third group: authenticated mac addresses
In your case table 11, next zone same story about the offsets.
This group is a bit trickier, one of the kernel patches of pfSense added an option to combine both ip and mac addresses in ipfw when an ip packet is matched, this is something that's not in ipfw and probably will never be in there. (different layers of the OSI model are combined here)
In our case this table also contains ip addresses, just like the second group.  The only difference is that it uses the firewall's arp table to determine what ip address should be valid based on the mac address.
So we need a network packet before we can do the allow, there might be a little lag.
A process in userspace should do the administration for this.

The periodic administration of both changing mac addresses and expired users should be handled by /usr/local/etc/rc.prunecaptiveportal, but when looking at the code I'm not sure this handles all correct now.
This could be one of the issues you have.
To confirm this you could go to the "ip addresses" page, edit an item without changing anything press save and look at the contents of table 9 again.
When this is populated, we might have caught your issue.

Because not all information is available in the ipfw table, there's an additional administration in a sqlite database.
In that database, all extra information is stored. This one is stored under /var/db/captiveportal*.db.
If the first apply didn't work, please remove all captiveportal*.db files and try that same apply again.
In case this fixes the issue, we know we have a cleaning issue after boot.

I hope this clarifies some of it and help fix your issue, although I'm aware that there's still a lot of work to do before this component is really as solid as we would like it to be.
(That's why it's on the roadmap for 16.1)

Cheers,

Ad

[ledoktre]

Thanks for the information.  I was able to confirm what you said was correct, and since I can't wait around for 16.1, I opted to *try* pfSense out and see if it was the same or if it worked.  It turns out, it worked just fine.  I'm gonna keep OPNsense on the back burner until I see the 16.1 come out.  It really has a lot nicer interface than pf, but at the end of the day, its working with captive portal as expected.

TY much for all your help and I'll def keep an eye on development.

Thanks,