Re: [pfSense] pf rule error
> The two are unlikely to be related. > > The "pf wedged" message can happen in some race conditions if multiple > actions are happening, attempting to hit pf in the same way at the same > moment. In most cases it's noteworthy but otherwise harmless. I had made several rule additions, removals and changes including the same for aliases. I was the only one accessing the UI and I had only one session. I have never seen it before so it's certainly not a consistent issue anyway. > There isn't enough detail in your description to speculate about why a > VLAN might have stopped passing traffic, but it's unlikely to be related > to a filter reload or pf in general unless you were changing rules on > the interface at the time. At the time we noticed the vlan stop passing dhcp requests there were no changes. In this scenario, all the devices had leases so when the issue truly manifested is hard to say. There had not been any rule changes on that interface anyway and neither with the dhcp relay on it. Given the nature of the traffic being broadcasts, I am not clear on how that became affected. Possibly some other technique could have resolved it but without knowing a reboot was my only option at the time. Thanks, jlc ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] About the Remote_Config_Backup documentation
Ref: https://doc.pfsense.org/index.php/Remote_Config_Backup The above mentioned page seems to advocate using wget with --no-check-certificate to poll the configuration from a pfSense box. This means a man in the middle can easily obtain the password of a user with access to the diag_backup page, which can also be used to restore the configuration and thus change virtually anything, including, I assume, granting himself better access. It also requires the credentials for pfSense to be stored in clear text remotely. The discouraged "Push it" solution at the bottom of the page seems like a much better choice to me. I also don't see why anyone should go through the hassle of setting up the web based config polling method when one could simply enable SSH login to pfSense and use a key without a passphrase to fetch the config. One is still storing the credentials, a key rather than a username and password, remotely, but at least this approach eliminates the man in the middle scenario and is less likely to break with a future update affecting the webpage. Why not simply advocate the use of SSH without a passphrase for both directions? One could even add an additional user configured with an sshd_config ForceCommand directive to "cat" the config to prevent the saved key from doing anything other than dumping the config file. The same could be done for "push it", to immediately start writing to a server-specified timestamped file and allow no other commands to be run remotely as that user. ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pf rule error
On 08/09/2016 09:46 PM, Joseph L. Casale wrote: > I recently received an error that the pf table was wedged and had been reset > while making changes. A few days later, a vlan stopped passing dhcp traffic > and filter reload did not resolve it, I actually had to reboot the unit. > > Has anyone seen this, are there configurations known to produce this behavior > or would hardware be the first suspect? The two are unlikely to be related. The "pf wedged" message can happen in some race conditions if multiple actions are happening, attempting to hit pf in the same way at the same moment. In most cases it's noteworthy but otherwise harmless. There isn't enough detail in your description to speculate about why a VLAN might have stopped passing traffic, but it's unlikely to be related to a filter reload or pf in general unless you were changing rules on the interface at the time. Jim ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Hardware and usage opinion
> A few years ago, we built a number of such units for customers, and for > our own use. 4x 10GbE NIC ports on 2 NICs, 4x 1GbE NIC ports on 2 > NICs. LAGed (actually multiple LAGs, typically ~4 per unit). Units > handled multiple gigabit inbound speeds without issue for a long time > (customers site). > > We've built a number of others for other customers. They usually come > in much less expensive and often significantly more performant than the > managed network/routers/firewalls from other places. Good to know the use case is not uncommon then. Thanks for the feedback, jlc ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pf rule error
> Check your states table size. Low, right now it is only at %0.002 full and while I don't have that info from the time of the failure I think it is safe to say it wasn't much different. Thanks, jlc ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
