Ah, running one side on pfSense itself will almost always be slower. Try testing between two internal hosts on different interfaces to exclude the WAN.

@whitephantom Check that the connections themselves are capable of sustaining the needed bandwidth. Install the iPerf3 package on both pfSense boxes and do a transfer test in both directions, use -R switch to reverse directions. Ensure sure that both sides are AES-NI capable. Without AES-NI encryption performance will be poor. You can test AES performance with openssl. Run this in the pfSense shell on both sides: openssl speed -evp aes-256-cbc And this too: openssl speed -evp aes-256-gcm Post your output here. You should see something like this: Benchmarked CPU: Intel Celeron Processor N5105 Doing aes-256-cbc for 3s on 16 size blocks: 109174474 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 36252639 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 256 size blocks: 9295310 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 1024 size blocks: 2318898 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 8192 size blocks: 289695 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 16384 size blocks: 145956 aes-256-cbc's in 3.00s OpenSSL 1.1.1n-freebsd 15 Mar 2022 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 583784.13k 775408.93k 795270.80k 793583.81k 793125.91k 797114.37k Doing aes-256-gcm for 3s on 16 size blocks: 69574566 aes-256-gcm's in 2.99s Doing aes-256-gcm for 3s on 64 size blocks: 43887920 aes-256-gcm's in 2.98s Doing aes-256-gcm for 3s on 256 size blocks: 21807074 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 7073429 aes-256-gcm's in 2.99s Doing aes-256-gcm for 3s on 8192 size blocks: 952031 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 16384 size blocks: 475160 aes-256-gcm's in 2.98s OpenSSL 1.1.1n-freebsd 15 Mar 2022 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-gcm 372033.19k 941177.59k 1860870.31k 2420701.01k 2599679.32k 2608593.57k The aes-256-gcm cipher is probably the best cipher to use for IPSec assuming both sides support it.

Ok, you won't get 300Mbps over a VPN but since that's download only you're far more likely to be limited by the 30Mbps upload which it should handle no problem. Steve

@stephenw10, et alia: I did come up with a resolution to this concern and wanted to publish my results should such guidance be utilitarian to someone else's endeavors. I first started by upgrading the RAM in my HP T620 thin client to 16GB and thereafter installed ProxMox thereupon. pfSense was then installed as a VM under ProxMox (the network device used for the VM was "virtio") and succeeding this change in how pfSense was instantiated pfSense has never lost its WAN connection since. Moreover, I now have the added benefit that my pfSense VM can be live migrated to a different ProxMox cluster member and as well be configured as highly available (from a ProxMox point of view). I hope one day that pfSense can support its own HA architecture without requiring multiple internet facing static IP addresses. With all the virtualization technology available today this ought be possible (using a virtual switch or virtual IPs). Thank you to everyone for providing input on this concern and I wish everyone a most blessed, healthy, happy, and safe (thug-free) year. Stuart

@stephenw10 said in Support for RTL8111F?: pciconf -lv I think you are 100% correct, I do not see the card. Thanks a lot for confirming! It must be a USB device only I imagine... Oh well!

@yogibaer said in Sophos SG 115 Rev 2 to pfsense or opensense: @fireodo no, I deposited the setting in the loader.conf. So should I better create a new file with the name: loader.conf.local and store the command there. Yes - as I mentioned, the settings will stay even on a system upgrade (loader.conf gets overwritten on a update/upgrade)

Hi. I'm trying to do the same for an embedded system. Did you ever get this to work?

@provels said in pfS on Sophos SD-Red 60 Hardware?: see the proc Or a well-formed search query. Max Throughput: 850 Mbps | CPU: ***NXP LS1043A***, 1.6 GHz, 4 Core | Memory: 1 GB DDR3 | Storage: 4 MB NOR Plus 256 MB NAND. LS1043A: https://www.mouser.com/datasheet/2/302/nxp_phgl-s-a0004270254-1-1750392.pdf [image: 1672071196487-e54bd2e2-54b2-4001-8757-2b86fe2658b9-image.png] ARM = no pfSense from ISO/IMG. You could manually build it but you will find you have issues with device drivers.

@darkk Interesting. I get a handful errors appearing on the Out interfaces for VLANs when there is a system restart. After that, they stop. Maybe related. I don't know.

@stephenw10 I'm thinking it needs all CPU cores in order for the temps to work properly. Thanks for the help. Happy holidays!

They must provide a client application to run on whatever is being shutdown. The cable probably only needs 3 connections and one will be GND so you can test for that. You can probably 'find' Tx and Rx with some experimentation.

Hmm, that's odd behaviour. It is possible for a NIC to become 'stuck'. If the OS configures it in such a way it becomes unresponsive it can remain that way until it's reinitialized by a complete power cycle. I'm not sure I've ever seen that on an em NIC though.

hi, thx for your reply regards

@stephenw10 Sorry for the delay. I figured it out finally. I have 3 different Dell R300 servers that were not working. To summarize the nics worked fine if I installed server 2022 and during boot. When I installed pfsense the minute it would get to configuring LAN WAN both link lights would go out and not come back on. Since they are old servers I updated the BIOS and reset all defaults in the BIOS. This did in fact fix the problem on all three. Thanks!

I would use something Intel X500 based given the choice.

EDIT: Scub my post. More testing has confirmed it is my internal cabling causing the issue. Cheers

@stephenw10 unfortunately not between these two machines. One is in a locked cabin on the ground floor, the second is in a server room on the second floor. This cable was layed out some time ago by electricians that support this building and can not be moved easily. I think I have tried this with a 10Gb DAC (copper) cable and got a link, I don't remember exactly. Will try that tomorrow.

I will contact the ISP. It is the fail with the reconnect.

@n1k You need D-21XX CPU's to get there....

Yes, this is unlikely to ever be supported be supported by pfSense. Looks like it already has some support over at OpenWRT though: https://forum.openwrt.org/t/watchguard-t-series/133452/8 Let the journey begin! Steve