well it died again this morning. I connected to the pfSense console and was able to ping out to 1.1.1.1 but couldn't connect to anything on my home network. A reboot fixed it. What can I look for to find why this is happening? btw: I upgraded to 2.5.2 a few days ago but can't change the title of the original post

@jimp All the detail is in the Config History section. Feature request submitted: https://redmine.pfsense.org/issues/12118

I made the changes again since the previous config save. Then downloaded the xml for safe keeping. Attempted to put the device in production but it wasn't working. So I took it back down and tried to see what's up. Now it's bootlooping, orange LEDs flashing every minute, never comes up. This is a brand new device and even if it could be wiped, reloaded, I'm not gonna put such an unreliable device in production. RMA requested.

@p32spaceblaster so I just noticed this has stopped again. It may have to do with performing updates on my Ubuntu log server and when I do a reboot but I've done this the same way for some time and had never noticed it. I feel like this is something new. I'm going to monitor further and see if I can replicate it. I think pfsense fails to ship logs sometimes after I reboot my log server.

@JKnott @NogBadTheBad Thanks for your help. Indeed, the hardware was limiting our bandwith. Exact same configuration with the Netgate 7100 and we reach the 500/500 easily.

@terrencettibbs said in Calling all "MR BEARDY'S" Help needed for config migration from 4 PORT 1GIG NIC to 2 SFP+ NIC: As there is an apparent insufficient supply of MR BEARDY'S left in the world to answer my post, I thought I would give it a go and I must say I am rather impressed with myself. FKN GOLD

@kom ok, I understand you ... I'm using DNS Resolver, I already had my website added to the Host Override list ... I don't know if my problem is the consequence of some protocol conflict between my proxy and Cloudflare, because it was just after having added SSL certificates for using HTTPS on my website, which presented me with the problem ... I used HTTP before.

The WireGuard package is considered experimental because it has only recently been added and I'm sure there will be things discovered. I use it here though and have not seen any issues for a while now. The current package version seems good. The lack of OpenVPN interfaces there is probably not a bug, more likely the presence of WG interfaces would be. However you can open a feature request to add them: https://redmine.pfsense.org/projects/pfsense-packages Steve

Whatever local clients those are on 192.168.0.30 and 192.168.0.45 are sending a POST to the firewall web server. You'll have to see what's running on those to know what they're doing.

I didn't read carefully, and didn't see that in your question you ask for 2 separate subnets int1, 192.168.100.100/24 int2, 192.168.200.200/24 Subnet1 192.168.100.0/24 Subnet2 192.168.200.0/24 So, I changed my test but the result is the same. 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:78:d8:01 brd ff:ff:ff:ff:ff:ff inet 192.168.100.141/24 brd 192.168.100.255 scope global dynamic enp0s3 valid_lft 86383sec preferred_lft 86383sec 3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:78:d9:01 brd ff:ff:ff:ff:ff:ff inet 192.168.200.141/24 brd 192.168.200.255 scope global enp0s8 valid_lft forever preferred_lft forever # arping 192.168.100.141 ARPING 192.168.100.141 60 bytes from 08:00:27:78:d9:01 (192.168.100.141): index=0 time=377.666 usec 60 bytes from 08:00:27:78:d8:01 (192.168.100.141): index=1 time=427.840 usec But this is a configuration on virtualized environment, without any smart/manageable switch. All my PC/servers are connected to netgear non manageable gigabyte switch. I think, when you have this kind of complex configuration (router, multi-subnet, ect.), you may need manageable switch which can separate VLAN and use spanning tree and others features like that. I don't really know because I don't have a manageable switch for the moment, but I'm looking to buy one to test :)

@keyser Huge thanks!

@gabacho4 Thanks for getting me over the first hurdle. I've now got my device configured as a rudimentary hardware firewall, with all of the basic settings ... I'll see if it will play nicely with my WiFi router, and if that is not an unmitigated disaster, I'll work through the documentation and see how VPNs and other layers can be added incrementally.

@gertjan, thanks for your wisdom on your replies. You were 100% right. I ended up opening an enterprise ticket to see what support had to offer. I ended up having to export the config.xml, rebuild the box from the recovery image and then import the config.xml back. Now the box is back to 100%. It might be a good idea for Netgate to put some "stops" in place when an XML is exported on intel and a restore is attempted on ARM. It was interesting because there were zero errors. It was not until after the box was up and running that I noticed the error. Anway wanted to reply back on this thread and close the loop. Thanks again!

Try running at the CLI: pkg-static -d update What error is shown? You might need to set the update branch to 2.5 dev to allow it to pull in the repo updates. Then set it back to latest stable when that then shows as 2.5.2. Steve

@stephenw10 said in For The Suggestion Box: It is generally preferred to restore the full config to avoid any config version problems. I would agree.. But I could see maybe restoring a couple of them only if you were in the middle of messing with those.. But yeah I would think there shouldn't be any reason not to just restore all, since you didn't mess with any of the other things during a specific sort of project.. But I don't see why you would just backup couple of them.. Its a few K at best.. not like hey I only need to backup this that is 1MB vs 100MB

Do you have a multi-WAN configuration? If you do, there is a known bug in 2.5.1 with port-forwarding and a multi-WAN setup. The bug is fixed in the 2.5.2-RC (that will be released soon). Here is that bug report: https://redmine.pfsense.org/issues/11805.