@phil.davis: If the upstream device is in "router" mode (you have a private "local" subnet between pfSense WAN and the router) then by default the pfSense WAN will be monitoring the local address on the upstream device. That address will still respond, so pfSense thinks that the link is working, when actually just the cable from pfSense WAN to the upstream device is working. Edit the gateway on each WAN and choose an alternate monitor IP - something that pfSense should be able to ping upstream. e.g. some reliable fixed address at the ISP, or Google 8.8.8.8 8.8.4.4 etc that will indicate that the "internet" is available. Yeap monitoring ip is the key, now when i plug off the fiber cable from router it's switching to WAN-2 in 5 seconds, once more thanks phil :)

@phil.davis: Each single state ("thread" of download/upload) has to live on a single WAN. To the upstream server the packets back and forth have to come from/to the same WAN IP. So a single-threaded download can only run at the speed of the WAN which it gets allocated to. When the WANs are equal bandwidth, the strategy is to put each new connection onto the next WAN, spreading then umber of connections on each WAN equally. Statistically then the WANs should experience about equal load (e.g. if there are 50 "connections" on each then it is likely that the "connections" that are actually wanting lots of bandwidth will be spread between the WANs). If there are only a few connections, then maybe the ones that want bandwidth happen to have been mostly allocated to WAN1 and those that are more idle are on WAN2. In that case, bad luck, WAN1 will be saturated while WAN2 has free bandwidth. If there are significantly different bandwidths on each WAN then you need to put weights on the WANs in the gateway group (they are on the GUI), so that most connections get allocated to the WAN with more bandwidth. If you use a download manager that downloads bits of the file in parallel, then it will make multiple connections and those will (most likely) be spread around the WANs in the gateway group. So you could see total file download speed near the summ of the WAN speeds. Note: You did not mention doing anything with rules. You need to put a rule on LAN that will feed traffic destined for "the internet" into the gateway group. Without doing that, all your traffic will just go out the default gateway. @phil.davis thanks for explanation,now it's much more clear for me,you are right i forgot to mention about firewall setting,i did configure as you mentioned, with IDM downloads speed makes different (it uses two WAN at the same time). Thanks for your time.

@kpa: "Won't it be great when we can run everything virtual without any underlying hardware at all." ::)  ::)  ::) What is your hypervisor running on then? Cosmic energy?  ;D That's what I am hoping for one day, but without quantum fluctuations that will introduce random bit errors.

If this works OK in 2.3.3 it will probably work OK for any further 32bit releases which will probably also be based on 10.3. Steve

That sort of error is almost always a hardware problem. Though I would usually expect it to have random offsets. You might be OK with running a filesystem check from single user mode a few times, or reinstalling. But I wouldn't count on those working 100%. It isn't likely that a change in pfSense from the upgrade caused the problem necessarily. It might be that the amount of writes that happened during the upgrade brought out an existing problem in the disk. How long ago did you purchase that unit? Is it still under warranty? If so, or if you don't know for sure, contact us at support@netgate.com and we can look into it. If you know it's not under warranty, you have a couple options. If that unit was using the eMMC then you could add an M.2 disk and install to that instead. If it was using an M.2 disk already, you could replace it with a different M.2 disk, or remove the M.2 disk and install to eMMC.

@doktornotor: Seems like you need better hardware. It's the C2758 model, it sounds weird, is not it?

Hi and thanks James. I reinstalled the firmware using the downloaded link you supplied. All good. I did lose all my configs and certificates I had created in the last 2 months (recovery of them didn't work), but i had a backup from December which got me partly back on track. Kind regards and thankfully it's not become faulty with the update. Andy

upgrade to 2.3.3_1 doesn't reboot? and powered off and on doesn't come back on… same device. similar if you ask me... probably the actions taken after are why we are at a different stage. in any case - my issue has been resolved by support

Thank you, that was the problem. I have it up and running.

Is this a request for help? Just a complaint? Share a few more details and I'm sure others would be willing to try and help troubleshoot the problem.

Nothing changed in the drivers, or even most of the OS. It is highly unlikely the problem was related to the update, and might have been from the reboot. That said, the configuration format of both 2.3.3 and 2.3.3-p1 is the same. Backup the configuration, reinstall from a 2.3.3 install disk, then restore the configuration. I'd use that as a last resort since it's likely a red herring and not the true source of the problem. Before doing that, I'd try the usual things like swapping cables and trying different switch ports, etc.

@mscher: The pfSense 2.1.1 did not work too. Yesterday I tested the pfSense 2.2 and it booted, but it is a alpha version. Then, does anyone have a solution for network adapter be recognized in pfSense 2.1.4? Were you ever able to get it working with the hp 331flr? I'm having the some problems. But I'm doing it on a mineitx, amd cpu. The lights on the adapter won't even blink when I have an Ethernet cable pluged in And if I try to boot with the adapter installed it won't even post it just keeps on rebooting.

start here: https://doc.pfsense.org/index.php/Interface_Bridges

The .img file is a disk image that is written to the USB memstick using dd, win32disk imager, rufus, etc. The filesystem format is UFS which few other operating systems can read, aside from FreeBSD. The fact that you can't see any files on there does not mean there is a problem. Try to boot from the USB memstick. If the hardware supports booting from USB and FreeBSD will run on that hardware, then it should work. There was at least one other person who managed to get it to work on similar hardware, but that might be a different model: https://forum.pfsense.org/index.php?topic=116910.0

That went into the right direction. I had defined the LDAP server by FQDN. But during testing, there was also a problem with DNS lookups, so the server was not found. Instead defining it by IP address solved the problem. There had been some more challenges to take (WAN connections didn't come up right away…), but the process of exchanging hardware finally worked. What a relief!