@zoqask Just replying to myself having thought a little more about this. I suppose the hacky method would be remove the old card. Factory reset the box then restore the config and re-assign the new adapters to the appropriate rulesets. If there is a more logical way then by all means make the suggestion thanks.

@stephenw10 just to follow up on this whilst I have an open question in general. It was the clients broadband that was at fault. Having done some digging they got the line back up and PF sprung to life. That site has had up times of nearly a year before. A real testament to the kit and OS (PF).

@s0m3f00l said in SG3100 random PHP crash - 2.4.5-RELEASE-p1: /usr/local/www/diag_command.php Hello! I dont think this php script will run randomly. I have only seen it run from the gui Diagnostics -> Command Prompt menu item. Whatever command was run probably generated a huge amount of output for the browser and ran php out of memory. Check... clog /var/log/nginx.log | grep diag_command.php ... to see when that command was run last and maybe by whom. John

@antonio-briguglio Glad you finally got it sorted.

Looks like igb3 works exactly as expect there then.

@biggyk Check the system log. It may possibly provide hints.

@mlaustin said in Shutdown corruption: @stewart The current one is Intel. The other one I purchased is Intel Pro 1000. They are not Realtek cards. I'm curious since you said the 4-port card was inexpensive so I was wondering what model you purchased from where. Glad you got Intel, though I've never experienced real issues with Realtek cards personally.

@azdeltawye Me too, except I use apcupsd.

The port forward was failing due to a routing issue caused by the oVPN client connection. The baseline config documented by the provider had not mentioned that it would pull routes for the below and I hadn't noticed: 0.0.0.0/1, 128.0.0.0/1, 2000::/3 I had masked the issue by explicitly defining the gateway used by outbound Rules. Once the option "Don't pull routes" was enabled in the oVPN client config, the port forward was happy and the gateway no longer needed defining in Rules. I've requested of the oVPN provider, PIA, to include this as a heads up in their guide....and now I am more aware of the routes. The webserver's response now shows as expected from the internal interface. [image: 1616549857857-outbound.png] Thanks to @its_maek for documenting their findings in this netgate forum topic! VPN Server from Private Internet Access (PIA) created a route 0.0.0.0/1 when the interface is created. In OpenVPN client I had to select "Don't pull routes" and it no longer makes that route. pfSense 127.0.0.1 now properly goes through the default Gateway.

@stephenw10: I posted somewhere else, how I ended up solving this problem: https://forum.netgate.com/post/974122.

@lanna said in Half speed upload on all WANs: so if upload line speed of ISP is 200 Mbps, all clients only get 100 Mbps upload. I believe that the 200 Mbps would be true if all clients are equal. Let's hope an expert on traffic shaping chimes in; however, I think the 200 is been divided among all clients.

When you import/restore the config file it should prompt you to assign new interfaces (e.g. assign WAN to igb0). You can also manually edit the .xml config file before restoring if desired.

@alanesi Restart solved the problem.

I ended up downgrading back to 2.4.5-p1 and everything is fine again. Maybe there's something specific to our configuration, but even with Netgate hardware, it doesn't look to me that 21.x is ready for prime time just yet. Maybe it's just us. In case it helps anyone, there were at least three show-stopper issues that we found before we gave up: 1 ) Severe routing latency between vlans 2) DNS Resolver (unbound) crashing if "Register DHCP leases in the DNS Resolver" is enabled. 3) OpenVPN completely unusable (users can't connect, widget says there is a problem, services say everything is fine).

I ended up downgrading back to 2.4.5-p1 and everything is fine again. Maybe there's something specific to our configuration, but even with Netgate hardware, it doesn't look to me that 21.x is ready for prime time just yet. Maybe it's just us. In case it helps anyone, there were at least three show-stopper issues that we found before we gave up: 1 ) Severe routing latency between vlans 2) DNS Resolver (unbound) crashing if "Register DHCP leases in the DNS Resolver" is enabled. 3) OpenVPN completely unusable (users can't connect, widget says there is a problem, services say everything is fine).

@lastb0isct Did you ever manage to figure this out? Running into the same situation as you are.

Unfortunately, Amazon Prime Video still wasn't cooperating so I had to disable blocking altogether. Here is a link to the documentation. Snort Pass Lists