Thanks
Get

Thanks, it should be fixed now.

I had pointed it to a saved 2.3.3 report that I deleted yesterday when cleaning up things post-release.

there is no "free' book.

https://doc.pfsense.org/index.php/Main_Page

I should point out that I'm happy to be proven wrong on this, and hopefully this post will show up on a few searches in the future for others that are having a similar issue.  :)

If your primary concern is that the hashes are on the same server as the files, then that isn't always the case: When you download a file from pfsense.org using the download selector it shows you the hash on that page, served from the web server and not the same server that is sending you the img.gz/iso.gz. That should be sufficient verification for the majority of cases.

There was one SSD which shall remain nameless, when TRIM was enabled it suffered complete filesystem failures 100% every time.

We aren't going to keep track of other vendor's hardware with any risk like that. If someone wants to track down the info, fine, but the moment we put something like that up and someone loses data it'll be on us. If someone wants to put together some info in a post, perhaps a sticky would be OK, but not on the wiki.

Without commenting on the architecture and reasons for it, your problem will be that Internal pfSense WAN will block traffic originating from outside it (i.e. trying to ping from external back to 192.168.20.2).
At the VM console of Internal pfSense you can use the developer shell and enableallowallwan (its called something like that). Then you can get into the webGUI from upstream of WAN and sort out a more restricted set of rules for access to the Internal pfSense webGUI from upstream.

Depends on what you look for in the book, but most of the content is outdated.
Better sources:
-> https://doc.pfsense.org/index.php/Main_Page
-> the new pdf / online book (requires subscription)

@Nullity:

I gave you the same answer last week on the other forum. Anyway… ::)

Oh, I thought you were referring to something else over there.  You had mentioned ipfw and MAC based filtering causing multiple passes through the stack, and that confused me.  So, are you saying that enabling bridging causes ipfw rules to be created and all traffic getting passed through ipfw AND pf even if there's only L3 rules involved?

If so, that'd be a bit more overhead than I thought!

@Nullity:

Similar to your "What is wrong with bridging?" question, I would ask you "What is wrong with routing?"

In a general sense, or in the specific case I referenced?

For my specific, the issue with routing is that IPv4 network broadcasts aren't routed.

Thanks for pointing out and fixing, looks good to me!

I've pushed a fix for that or 2.3.2-devel snapshots

It should not need to be moved unless something was done to the default rule (e.g. gateway set) or someone added a block rule.

Thank You very much.

Fixed, thanks!

I was experiencing very poor performance with my CF based install so I did try with dma enabled and disabled. Didn't make any difference in the end,the cause was bug 2401, as detailed in the errata to the 2.2.4 release

As an aside it's a bit much to expect new users to start by reading the errata to the release before last! It may be better to mention the issue with slow CF cards and how to fix it somewhere more prominent on the wiki.