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 ;)

It's missing some info, such as the message log/buffer with the other part of the kernel panic message. Can't tell much from what you have. It doesn't look familiar, it's crashed in an operation on an OpenVPN tun device. Can't say I've seen that one before. Could be hardware, but hard to say with any certainty.

1. Make sure you are using pfSense 2.1.4, not 2.1-RELEASE as the OP of the thread was. 2. From the console menu, try the option to reset to factory defaults. If that fails, try: cp /conf.default/config.xml /conf/config.xml

I'm no expert but here is what I think. pfSense does not have any built-in tamper detection that I am aware of other than IDS like snort or suricata.  You must use other tools to enforce the use of the proxy, such as firewall rules, domain policy, WPAD policy etc. HTTPS proxy support requires SSL certificates to be installed or manual proxy configuration on each client, but it can be done.

It all depends what your WAN connection is as to what's 'normal'. However 25% packet loss looks pretty bad. Steve

Your initiator shouldn't be sending the connection to the gateway, have you tried using the server local IP address instead of the FQDN instead? The machine/ dns server might not be resolving your fqdn to the internal server ip.

It's normal.  The continuous ping is to allow pfSense to ascertain that your upstream gateway (in this case, it's your modem/ router) o verify that the connection is active and usable. This is helpful in multi-WAN connections where the router can detect connection failure on one link and switch to the next.  It's also used to restart certain services or connections to force downstream services to change their state to reflect the loss of connection. The ping latency results are also used to generate the link quality RRD graph. You can change both the frequency and the destination to ping - you might want to change this because your router can be up and contactable but the actual internet link may not be. To do so, go to System -> Routing -> Gateways.  Click the "e" button next to the default gateway. Under Monitor IP, enter an alternative IP address that is on the internet and contactable through your link.  e.g. Your ISP's DNS server IP or Google DNS server IP Click on Advanced to expand it. Under Probe interval, enter a new value (in seconds) to change the interval between pings.  If you are using an external server, you might want to increase the interval in case this behaviour is deemed to be an attack.

I know the people I have suggested them too have been very happy and get great speeds on the ones I have tested have more than capable of solid 100mbps connections.

@BBcan177: Google "Fatal trap 12: page fault while in kernel mode" and there are lots of people with that error. What kind of machine is it? Are you virtualizing this machine? 'tIs the first machine in my sig, BB; not virtualized  ;D I don't think it was hardware; I uninstalled these packages mentioned before, and so far no hangs anymore. I'll see what happens next.

Thank for answer Can you tell me how to block free proxy or anonymous proxy?

I won't be able to help out any further alexxtasi. You've exceeded my ability to assist through the forums. It's often difficult enough to get the base system running properly because of it's numerous bugs and quirks much less when you customize to the extent that you have. Good luck my friend.  :)

LOL, never mind guys i have resolved this issue, the problem as usual, was with the meat-ware .. rolls eyes have a great day .. ;) Cain