Hi,

I use "Enable per-user bandwidth restriction" (checked) - using these settings: 2500 (Kbits upload) and 700 (Kbits download).
It works pretty well for me, when I test speed limits with my iDevice.

Slow portal behavior seems more a DNS issue to me.

I remember seeing that when add MAC on the "pass-through-MAC" page, the speed settings over there aren't taken in account (bug ?!).

Hi,

I am experiencing the same issue right now on my captive portal radius authentication setup.

I am getting an error every time I try to re-login for the second time, first time produces an error. This is the error:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4294967295 bytes) in /etc/inc/radius.inc on line 446

I've tried to follow you "too long" secret key suggestion but it did not work for me. Anyway, maybe you have some other idea about what might be causing that error.

thank you Gertjan for your reply, user is connected to the internet after i tested your advice but a error page is appears after logging in :(
anyway i tried another method by created a new page only contain a green right mark logo with done below then uploaded as (Logout page contents) and activated (Enable logout popup window) feature, it is working properly as i want .

thank you again

@Gertjan:

@gregoryzero:

DHCP-server log shows this:

dhcpd: send_packet: Permission denied Failed to send 300 byte long packet over bce1_vlan30 interface

Well, that's clear enough.

I guess: undo all the vlan-stuff and all starts working. Start digging in that direction.

It seems, that everything will be easier…
I applied the 2.1.4 update and it seems, that this issue has been resolved.
Thanks everyone for help.

I can't think of how you would accomplish this without either…

1.) turning on DHCP at the access point
2.) adding another interface to pfSense to connect the AP to
3.) adding a managed switch and creating a VLAN (not sure steps, but think you could do it.) attaching the AP to the appropriate port.

Hi there.

Your post is missing some info.

What does this command show you:
ipfw -x zone1 show

and this one:
ipfw -x zone1 table all list

Note 'zone1' should be the name of your zone - as shown on the Service :: Captive portal or Status :: Captive portal

Tell us a little bit more about your setup.

While you're at it, 2.1.3 is old (login to pfSEnse and it will tell you so) => upgrade.

Hi,

"offline generating" of vouchers as such is not possible, pfSense needs to now somehow which vouchers are valid and which are not…

Maybe setting up a VPN to the pfSense-Box could help? Someone created a REST API for pfSense Vouchers (http://blog.digitalhigh.es/pfsense-voucher-rest-api/), you could build something on top of that, but you still need access to pfsense though…

Best regards (or "Viele Grüße"  ;)),
Eagle2

Hi.

Yep, I think I know what you mean.
When shifting to 2.1.3:

2.1.3-RELEASE (amd64)
built on Thu May 01 15:52:13 EDT 2014
FreeBSD 8.3-RELEASE-p16

Update available. Click Here to view update

.
[oops: a n update just came out several minutes ago  :) :))

I also saw strange stats.
Some how, the upgrading of the portal RRD stats (adding the concept of different "zones" etc messed up the RRD data.

I managed to keep thing going by removing deactivating the portal interface in the old pfSEnse version.
Remove ALL Captive portal settings from the config file - this and everything between it:
        <captiveportal></captiveportal>

Upgrade - RDD will be handled fine.
Activating the captive portal again.

I guess I saw how new stats where generated.
I wiped these Captive Portal stats files.
Renamed my old RDD stats file to the new one.
Done.

I know, this is what is being called 'some jacking' but it worked for me.

I finally used other methods to stat: this is from my server on the net: http://www.test-domaine.fr/munin/dyndns.org/brithotelfumel.dyndns.org/index.html#portalusers

I guess i'm not that clear about the network i'm running.
My network has about 10 public access points all ubiquity, spans about 10 hectare or 25 acres.
I physically devided the network in segments, all connect to the pfsense server to its own network card.
All networks have its own dhcp server with different ranges, 10.20.1.1/24, 10.20.2.1/24, etc.
but all connect to the same captive portal, opt1.
All this was done for containing problems to a smaller sector, if problems araise (which did, multiple times) it doesn't bring the whole network down.

So this is why when people wander from one side of the site to the other they have to login again each time.

@abinjacob:

… because at the moment i'm manually deleting all expired IPs.

Expired "record" (== IP's) are just kept for reference.
and for this reason: If the same device (== the same MAC) comes back and the DHCP server finds the MAC in an expired record AND the IP is available, it will give the same IP to that device.
Otherwise, another IP will be given.

I do not understand why you should clean out the expired leases.

@abinjacob:

kernel: arp: 192.168.0.30 moved from 90:27:e4:f6:af:ec to 9c:20:7b:c4:27:ac on vr0

Me neither: but … the first message on this search list shows what the problem might be ; https://www.google.fr/search?q=kernel%3A+arp%3A+192.168.0.30+moved+from+90%3A27%3Ae4%3Af6%3Aaf%3Aec+to+9c%3A20%3A7b%3Ac4%3A27%3Aac+on+vr0&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla🇫🇷official&client=firefox-a&channel=sb&gfe_rd=cr&ei=YJupU4bwFOuXigbArIDQBw#channel=sb&q=kernel:+arp:++moved+from++to++on+vr0&rls=org.mozilla🇫🇷official

@abinjacob:

dnsmasq[31537]: read /etc/hosts - 144 addresses

Don't worry, this is insignificant is log-dust.
dnsmasq like to say this often, its ok. We all have these line several times.

@abinjacob:

one more system log which i'm not aware what this is
dhcpd: uid lease 192.168.0.222 for client 38:aa:3c:c6:9c:ce is duplicate on 192.168.0.0/24

https://www.google.fr/?gws_rd=ssl#q=dhcpd:+uid+lease++for+client++is+duplicate+on+
In 'my' words: the IP's / MAC's you put in a "Static mapping" have no 2 IP's for an identical MAC.

My advise: make your IP pool big enough, and restart the DHCP server. This list: "Status -> DHCP Leases" should be empty to start with, and you will be fine.

https://github.com/pfsense/pfsense/pull/1241

Merged ….  :)

I guess so.
Add a pass-firewall rule that only triggers with the first SYN packet between IP-client and IP-destination (no need to handle the rest).
You should latter on add the relationship between IP and login in USER, this is impossible to 'lookup' at execution time of the firewall - and IP-destination and its reverse.

But: this is pure theory. I leave it up to our government to track what users visit ;)

With already a couple of portal clients connected your pfSense box will bog down quickly. The syslog will probably not follow neither.

If you need to track users this way, you need some (very !) serious hardware - maybe some (pfsense) packages will fit your need.

thank you!

I only have a Wan and LAN interface. Why would I need a third interface?

It's good to keep fine tuning!

I set my dhcp scope from 192.168.0.60 through 192.168.1.250

I set my idle timeout to 2 hours and hard timeout 4 hours

my dhcp lease time is to 4 hours and max 8 hours.

@monsurvey1:

2. Any one know how to prevent the mac address spoofing, whether using the cisco switch or the pfsense box?

'Spoofing' can be done by any user.
Its a matter of of changing the MAC address.
You can't do anything to stop that. The user does it on HIS device.

Point 1: what about the most important device in a 'serious network setup' : a UPS ?

Hi,
Thanks, I did for the one week vouchers, the strange thing that the other time frame vouchers like one month does not effected and works fine. but maybe it will expired less than expected in the upfront days. Any way the one week vouchers seems works great after creating new roll.

As jimp already explained (implicit), you should intercept all DNS requests, and match them with the with listed domain names.
If you have a match, the resulting IP should be fed into the allowed IP list of the portal page. You probably have to issue en redirect to your client.
Some caching will needed, otherwise portal access will slow down as easy DNS request has to be filtered.

This is what I should call a "bounty project".

Gertjan:

I've got a baby on the way and have been pretty busy as of late, so it could take me a while to get back to testing this and provide the results of your posted commands. I've also got a buddy down the street from me who will assist in setting up a remote iodine server so we can test the tunneling techniques against pfSense.

cmb:

You're correct about the packet capture not showing any dns tunneling results. I must have attached the wrong capture that day. I was running late for meeting at work and had about 10 tabs open with various packet captures. I did have one that showed more details about the initial connection, but I apparently attached the wrong capture.

I'm not the only one that has had this issue though –> https://forum.pfsense.org/index.php?topic=65739.0

Digging more into the location requests, I believe this could be hardware fallback technique done by dish network for subscribers to properly pay for their pay-per-view purchases. Search results over the net show all kinds of results with people noticing that certain Dish devices are establishing a lot of DNS connections back to homebase.

I'll post back on this thread later after my buddy gets his side of the iodine setup and I have some more detailed packet captures to provide.

For right now, packetfence is fitting the bill and I don't show any established connections to 67.148.153.116 in the table states anymore. And he's still hanging off my guest vlan.