Easily missed.  ;)

@stephenw10:

It could be the Sonicwall device is using the same subnet on it's LAN that the pfSense box is using which is killing routing.

Steve

Went with 10.0.0.x on pfsense interface and 192.168.0.x on sonicwall.  It was pulling ip/subnet mask/etc from pfsense not still no actual internet connectivity.  Leaning towards the sonicwall being the issue here.

You're okay Stephen:) I was just thinking out loud and somehow it managed to get on the boards.

Take care:)

In my IT experience, BSODs(I'm from mostly Windows, but it should apply to kernel panics also) are mostly caused by memory and hardware like HD, graphics, NIC.

Sudden shutdowns, in my experience, seem to be more caused by PSU, CPU, chipset, heat(air flow, dead fan, whatever) issues.

PSU and memory are the easiest to replace and test. If you have two or more sticks of memory, there is a good chance you can just remove one of the sticks, but I'd recommend just doing a memtest for 24-48 hours. My guess is it's not your memory if it causes a power down, but it is easy to check.

@BBcan17:

This shell command will report free space for the file system.

**    df -h**

This shell command will report the Directory Tree

**  du -sk /***

If you use Suricata, or want to use Suricata, I would suggest increasing the Size of the Drive or you won't be able to use its logging and file extraction system very well with a small drive.

If you use Squid, you can also delete the cache or logs.

Awesome help, thanks.
After some info swaps with Bill, I'm going to stay in the Snort camp until Suricata gets true inline features.  I've got the drive back to 20% with little or no effort so I think things are happy for now.

Rick

Well, it's not the E3110, as it works fine on an Optiplex 755.  Apparently I stumbled upon 2 motherboards PowerD does not like.

In the RRD graphs 'm' means milli (10^-3). It uses that for numbers smaller than 1. 'M' means Mega (10^6).

Steve

Edit: Typo

So is this UDP or TCP.. You have both setup in the forward and firewall rules.

Nat reflection IMHO should always be last option..  Clients on the local network, should resolve the host of the service your trying to use to its local IP.  Clients on the outside should resolve to your public, and then yes be forwarded in.

AFIAK udp reflection doesn't even work, or there were issues with it that may have been resolved?  As to details your missing - for starters what version of pfsense are you using?  Is this pfsense a physical box or a VM?

You don't need a firewall rule. That traffic doesn't go through the firewall.
But if that interface is wireless then you need to enable communication between wireless clients. If it's a wifi NIC in the pfSense box that setting is called 'Allow intra-BSS communication' and it's on the interface setup page. If you have a wifi access point connected then it will probably also have a similar setting.

Edit: Typed too slow!  ::)

Steve

@stephenw10:

Have a read through this thread: https://forum.pfsense.org/index.php?topic=76538.0

Steve

@razzfazz:

If you're on 2.1.3, you can use the "System Patches" package to either either revert the original commit, or to apply my fix until a new build is released.

I went in and changed the two files in https://github.com/pfsense/pfsense/commit/d973a602abeab78803fce467198c571ba25ec0cb

Everything is working perfectly now.

Thanks again everyone. This case can be closed and marked as solved. Remember to make note of this if others come in with the same issue.

The RRD graph will be displayed as long as the relevant log file exists.
Reset RRD data will remove all log files and resolve your issue.

If you want to remove a single log file and keep the other data you have to remove it manually.
To do so, in Diagnostic > Command prompt execute "ls /var/db/rrd/*.rrd" to display all existing RRD log files. Then remove the one you want by executing "rm /var/db/rrd/<rrd file="">.rrd".</rrd>

Hi Hell0s,

If you edit the rule that you created to allow the Web access, scroll to the bottom of the rule and you will see a checkbox for logging.

"Log packets that are handled by this rule
Hint: the firewall has limited local log space. Don't turn on logging for everything. If you want to do a lot of logging, consider using a remote syslog server (see the Diagnostics: System logs: Settings page)."

Thanks kpa.

Like most errors where you bang your head in the wall for hours w/out any progress, it turned out to be stupid simple: lack of gateway.

It was that, combined with shitty consumer grade hardware with very poor configuration options.

After update pfSense always installs the latest versions of the packages, not the same versions that were installed before update, right?

Hi

Yes I'm using BT, will checkout the link thanks.

Andy

Run "ps uxawww" and then save that somewhere, come back in a couple days and run it again. See what is in the second list but not the first.

Yup, that's a better solution that just blocking things in the firewall.
It seems likely that your previous router did support IPv6 and was doing so correctly, hence no errors on pfSense. Your new router is inferior!  ;)
There might be more recent firmware available for it.

Steve

My first instinct would be to suggest that you simply replace the SonicWall with pfsense….. 8)

I understand that may be an ambitious start, and while I'm no expert at SonicWall, I seem to recall you can create a DMZ port in SonicWall.
You should be able to present that port to the WAN port on pfsense much as you would to an internet facing Web server.
That should let you create an IPSec tunnel to the pfsense box.  The LAN side of pfsense will have to "merge" with your existing LAN subnet, unless you're willing to dedicate a new subnet just for the pfsense IPSec.

If you can give some more details (and/or diagrams) about what you envision this setup to look like, maybe we can help you arrive at a solution.

Reset to factory defaults got me going here.  couldn't find anything less invasive …. :(