@xplozia The problem persist, but less often

Hi @jimp I have encountred another problem. I am doing these tests in pfSense 2.5.1.r.20210322.0300 version. When I export the OpenVPN User Configuration file from "VPN > OpenVPN > Client Export Utility > OpenVPN Clients > "USER" > Bundled Configurations > Archive" It generates a .zip file that contains three files: xxxxxx.ovpn file xxxxxx.p12 file xxxxxx.key file Are the xxxxxx.p12 file and the xxxxxx.key file the same that I can generate from "System > Certificate Manager > Certificates > "USER" > Export Key / Export P12"? I think that not are the same because this: I have generated a .zip OpenVPN User Config file. I have created a OpenVPN connection in a client with this file and works fine. I have changed the date of the pfSense to a date after the expiration date of the certificates of the CA, the OpenVPN Server and the User. I have changed the date of the Client to the same date of the pfSense. Evidently, the VPN Connection in the Client doesn't work because the Certificates have expired. I have renewed the certificates of the CA, the OpenVPN Server and the User. I have exported the .p12 and the .key files from "System > Certificate Manager > Certificates > "USER" > Export Key / Export P12" I have replaced the old .p12 file by the new .p12 file in the Client and the VPN Connection works well again. Then, I have replaced the old .key file by the new .key file in the Client and the VPN Connection doesn't work, not connects. That is, if I replace only the .p12 file the VPN Connection works but if I replace both files the VPN Connection doesn't works. I have exported a new OpenVPN User Configuration file with this new date from "VPN > OpenVPN > Client Export Utility > OpenVPN Clients > "USER" > Bundled Configurations > Archive". I have create a new OpenVPN Connection in the Client with this file and works fine. I have verified that the .key file that contains the .zip file and the .key file exported from Certification Manager have diferent sizes. If I replace the .p12 and the .key files of the old VPN Connection with the .p12 and the .key files contained in the new .zip file, the VPN Connection connects without problems. Best regards

@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).