pfSense

I am using the AMD64 builds of pfSense 2.0 RC3. I have the same build running on dedicated hardware and in a VM with CARP configured on both. The dedicated hardware was installed with a build of AMD64 RC2. When I setup CARP, I updated the dedicated hardware to the build in the VM and installed the VM using pfSense-2.0-RC3-amd64-20110708-1843.iso. I have updated four times since the install. The current build on both is 2.0-RC3 (amd64)built on Fri Jul 29 22:14:50 EDT 2011 and the previous version I tested was 2.0-RC3 Built On: Sun Jul 24 04:39:44 EDT 2011.

I noticed that my transfers were slow on the build I was on which was a build between pfSense-2.0-RC3-amd64-20110708-1843 and pfSense-Full-Update-2.0-RC3-amd64-20110724-0242. Connections were limited to 5Mbps (512KBps). This limitation was the same for uploads and downloads between all interfaces and the WAN as well as other interface to interface and VLAN to VLAN communication. My WAN connection is a physical link to to my gateway device and I have a 50/5 internet connection. My other interfaces are VLANs provided via 2 teamed GigE connections to a Cisco switch teamed with LACP. I do have one other interface that is a direct GigE connection to the Cisco switch. This is my management interface. This transfer limitation was the same no matter the interface I was on and was the same for the primary and backup pfSense devices.

My first step was to upgrade to pfSense-Full-Update-2.0-RC3-amd64-20110724-0242, but the issue remained. I could find no obvious reason for this limitation, but it only occurred when traffic has to pass through pfSense to get to the destination. Therefore, I removed the traffic shaper entries and my performance was at expected levels. I could pass 1.2Gbps (150Mbps) or more through the teamed connection with my VLANs while downloading at 50Mbps from my WAN connection.

I updated to 2.0-RC3 (amd64)built on Fri Jul 29 22:14:50 EDT 2011. The performance issue is still there, but I am limited to 10Mbps rather than 5Mbps.

I am not having this issue with build 2.0-RC3 (amd64) built on Fri Jul 8 02:49:42 EDT 2011 which I have running on hardware I have at home. I used the same options in the traffic shaper wizard on both devices. This build still uses the qDefault as the default queue which is set to a priority of 3 for all interfaces. The only other obvious difference is that this firewall is not setup to use Outbound NAT or CARP Virtual IPs.

The issues listed below with the conflicting queue priorities and the traffic shaper entries that could not be applied relate to the previous builds I tested.

I figured I may just need to reset my traffic shaper entries, so I ran the traffic shaper wizard, Single Wan multi Lan, and I get errors.

1) After it creates the entries, I find that all the interfaces other than WAN interface have a qLink queue rather than the qDefault queue. The qLink queue is set as the default queue, but is set to priority 1 which conflicts with the qP2P queue. I would receive an alert telling me about this conflict.

2) I changed the priority to 3 for all the qLink queues and applied the changes. After a bit I would receive an alert that the rules need to be explicit.

On another note, I am unclear on the benefit of the change from qDefault to qLink on all interfaces except the WAN interface in that the qLink queue is given a lower priority than qOthersLow. I would think that the purpose of qOthersLow is to set something lower than the default.