You might try a 2.7 install too, if that isn't one. The drivers there are from FreeBSD main.

Steve

@stephenw10 Wanted to close this thread by thanking you for your advice. You were absolutely right. I had to solve an issue with the pfSense box not completing boot cycle when not connected to a display but that was, in the end, just a cabling concern once I had the correct cable in hand... But then, reset the switch to factory defaults just to be sure, changed the desktop IPv4 settings to get its address by DHCP from the pfSense box and voila! she has WAN access now. Thanks again!

@stephenw10 , I work for a switching/routing hardware vendor, you'd be surprised at what is supported with BSD, the issue is that most of this code never leaves the private GIT repo of the vendors.

What is exposed to the OS, for these boxes is the physical switch ports, the appear as native ethernet interfaces like any other device, the core difference however is that you can adjust the behavior of the ASICs that connect each of the ports. The switch ports and intra VLAN switching will operate natively without any need for the control plane to do anything, since this is the defacto operation of an ASIC in an un-managed switch. As long as the ASIC has the instruction for the VLAN tags per port, it will operate like a dumb switch. If not then all the ports are basically operating on an common un-tagged VLAN, which is usually not wise.

The complexity start when you need traffic to exit a VLAN / IP interface. These boxes have the potential to operate as gen 1 or gen 2 firewalls that traditionally did not have custom designed firewall ASICs or FPGAs. These boxes would still use the CPU for inspection but would significantly reduce the cost point of a dense 1G or 2x 10G setup, with the basic assumption the CPU could handle 10Gbps of traffic.. which is unlikely for an Athlon.

I doubt that PFsense development community has the time justification for driving even basic port to port single ASIC development for the free community. Realistically when your dealing with 3+ 10G links, pushing traffic over the CPU is not really viable at those speeds especially not on a Athlon CPU.

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

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.