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

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:

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.