Diagnostics->Backup/Restore ??

Using an alternative bootloader is really only necessary in a tiny proportion of hardware and usually it would be for  systems that don't boot at all.
What hardware are you using?

Steve

Thanks for the answers.

KOM, bandwidth control can also be done by the Syno untill I can get it to work on pfsense. The only purpose of the VPN is to let users connect to the Syno for the cloud service. They will connect based on their own username and password. On the Syno I can configure guaranteed and maximum bandwith per user. That will give me some time to figure it out on pfsense.

@duncane:

You might try as well, It might as well be a bug of a policy applied uncorrectly following an upgrade of the firmware.

Changing this settings seemed to have fixed that on my side.

I'll give it a shot tomorrow, I just updated the firmware an hour or so ago, will see if that has changed anything tomorrow after work. If not, I'll enable the guest network and try it, then disable the guest network and try it again.

@Supermule:

Flaky switch??

I'm going to try exchanging the device plugged into the DMZ this weekend (it's a USB -> Ethernet adapter for Wii U, rather than a switch). I hope that solves the issue!

Ok Thank for your reply and i will follow your step. I hope i can do this as well.  :) :) :) :)

Thanks for coming back with a result, many don't.  ;)

Steve

Nice.  :)

One thing to be aware of is that to add NAT rules you will have had to switch to manual outbound NAT. That means that you have to remember to add NAT rules for any interfaces you now add, new NICs, VLANs, VPNs etc.
An alternative is to leave outbound NAT set to auto and add a gatway to the modem access interface. pfSense will now NAT that connection. Make sure your real WAN gateway is set as default though or your'll loose all internet access!
In 2.2 there will be a hydrid NAT mode where rules are auto generated but manual rules can be added. That will negate this issue.

Steve

Thank you very much.
In 2.1.4 you would sove it by using the guii
Diagnostics -> NanoBSD ->  Media Read/Write Status  -> Permament -> Save.

also, how do i reset the net.inet.ip.intr_queue_drops counter?

You've probably already worked this out, but squid + sarg will tell you by IP address (not user). But, you can assign IP addresses to specific MAC addresses with DHCP. Captive Portal by default links the usernames to the MAC and IP addresses… so the squid report should work for you.

As for storing the data off the firewall I would use rsyslogd or failing that look at options for a network mount (NFS or SMB/CIFS).

https://doc.pfsense.org/index.php/Copying_Logs_to_a_Remote_Host_with_Syslog

I think you are asking for help in determining why pfSense is blocking the radius packets?

Can you sketch out a topology? i.e.

WIFI CLIENTS <–> [ARUBA 7200      ] <–> [LAN  pfSense  WAN] <–> Internet
                  Radius client &        RADIUS service &
                  Captive Portal          User database

@KOM:

Pfft.  You don't get to play with the big boys until your apinger packet loss is >100%.

This is a known issue that only affects some users.  Restarting apinger seems to clear it, if I remember.

Thank you, That helps.

Bizza wonder what is causing the slight degrade on speed.

Well, that's the hardest thing I have every done. Made a copy of the file bandwidth_by_ip.php and commented out the line require_once('guiconfig.inc'); and viola! No authentication needed to get my bandwidth readings :D

Now, to think of a more permanent solution. (but play time first)

Hey guys,

Thanks for your help. I think it's solved! In the shebang I had

/use/local/bin python

as opposed to

/use/local/bin/python

since then and removing "python" from the crontab entry it seems to be working!

Thanks again.

Ok, I think what you are asking is why can the [same] client machine achieve good test results when behind a firewall but poor test results when connected directly?

I don't think you've mentioned any specifics about the client machine, so I'm just guessing, but pfSense is FreeBSD based and generally performs exactly the same as most FreeBSD clients especially when software versions are identical and installed on identical hardware. Also - in my experience - FreeBSD generally performs identical to Linux clients and usually outperforms Windows and OSX clients. If you are testing with a Windows or OSX client your results are not unusual. If you're using a FreeBSD (or linux) client on similar hardware then I would suspect a configuration issue or even possibly a speed/duplexity mismatch. Are you doing your performance testing with identical hardware and identical operating systems?

It seems from the information provided that pfSense is performing properly, and it also seems the client should be able to produce identical speed test results but is not, so if I were working on this issue I would begin by troubleshooting the client. Starting with the basics, I would reboot every device in the test setup and then first check that the speed and duplexity matched up for the client test. If that looked good, then I would check the interfaces on each device for errors and if that passed, I'd probably start eliminating variables and try a different cable, client, then modem.

^ since this thread is a year old I doubt this is still and issue bahs ;)