pfSense

Hi, can you let me know what information would be useful?

At present, the only system logs immediately preceding failure are:

May 5 17:15:22 pfsense check_reload_status: syncing firewall
May 5 17:15:27 pfsense check_reload_status: reloading filter

When pfSense has hit this issue, I connect to the console and press 9 for "pfTop". There I see all my traffic being blocked. Pressing 8 for "Shell" and executing /etc/rc.filter_configure resolves the problem instantly.

The issue only pops up occasionally (more often for customers, some how..) so, I am writing scripts to repeatedly attempt various tasks (just reload, add NAT then reload, add rule then reload etc..) to try and narrow it down a bit.

Are there debug flags I can set to get more information from pfSense, during this process?

Thanks,
Aaron

pftop shows only traffic being passed, not blocked. check /tmp/rules.debug and the loaded rulesets and other info in status.php

Somehow it's skipping the entire user generated rules section. The only way that entire section is skipped is if

if(isset($config['filter']['rule'])) 

Try the same config on a clean install with no packages.

This system has 1 package listed in "Installed Packages":

Package Name: RRD Summary
Package Version: 1.1

I'll post again, once I have thoroughly tested an install with no packages.

Thanks,
Aaron

Hi,
I have tested with a vanilla install of pfSense.

I consistently encounter this issue. I have tried i386 pfSense, amd64 pfSense and 64 bit and 32 bit KVM virtual hardware (including 32 bit pfSense on 64 bit hardware).

I have also toggled APIC, ACPI and PAE emulation on the virtual hardware.
I have tried with 1 and 2 CPUs.
I have tried enabling and disabling ACPI within pfSense.
I have tried installing the virtio drivers and enabling virtio on the virtual hardware.
I have tested using kern.hz values of 10, 100, 1000

The only changes made to this pfSense install were to add the line:
$nocsrf = "true";
to a couple of the web scripts, to make it easier to use a script to trigger the fault.

Any assistance you can give would be greatly appreciated.

Aaron

Similar problem here:

Hardware: Fujitsu Primergy; VMWare VSphere

pfSense 2.0-RC3 (amd64)
built on Mon Jul 4 16:49:48 EDT 2011

'Reload Filter' breaks any ssh-connection. This happens any time I click the button at status_filter_reload.php and every 15 minutes due to

0,15,30,45 * * * * root /etc/rc.filter_configure_sync

in /etc/crontab.

The only information I can capture are log entries of an openVPN-client (pfSense is listening on port 1194):

Jul 18 09:30:02 MY_CLIENT ovpn-client[29701]: TCP/UDP: Incoming packet rejected from PFSENSE.IP.ADD.RESS:18080[2], expected peer address: PFSENSE.IP.ADD.RESS:1194 (allow this incoming source address/port by removing --remote or adding --float)


No idea why the port changes.

I found the solution for my problem with broken states on filter reload:

I had to activate 'States' under System -> Advanced -> Miscellaneous -> Gateway Monitoring.

This link was helpful: [[http://forum.pfsense.org/index.php/topic,34905.0.html]]

The same solution worked for me. What I was seeing was broken ssh connections on every filter reload, any in-flight webconfigurator requests would stop loading, etc.

The default behavior seems wrong. Maybe the text should advise to always turn this on if you're using multiple gateways? Or perhaps just assume this behavior for only a filter reload but allow the feature to work in the event of a real gateway failure?

I have that same bug in the following pfSense version: 2.2-RELEASE (i386)
built on Thu Jan 22 14:04:25 CST 2015
FreeBSD 10.1-RELEASE-p4

After changing and applying a port forwarding roule the firewall ist blocking all traffic. If i call /etc/rc.filter_configure from command line, everything is fine again. Is there a fix or a workaround for that bug?

I can confirm that I am experiencing the same with 2.2-Release (AMD64) version.

Any updates on this?

nothing you're encountering today has any relation to this issue. I suspect any such issues on 2.2 have the same root cause as #4445. It appeared to be Hyper-V specific, but the same root issue could apply elsewhere, it's potentially more hardware/hypervisor-specific than specific to just Hyper-V (actually seemed to be more its block driver).

Chris Buechler wrote:

nothing you're encountering today has any relation to this issue. I suspect any such issues on 2.2 have the same root cause as #4445. It appeared to be Hyper-V specific, but the same root issue could apply elsewhere, it's potentially more hardware/hypervisor-specific than specific to just Hyper-V (actually seemed to be more its block driver).

Hi Chris, reading #4445 it seems that you are right because I am also using hyper-v, will follow that bug now. Many thanks