@stephenw10 Ok, thanks a lot!

Hello, I'm currently experiencing similar issue. My WAN keeps dropping every few days. I couldn't figure it out until I read the gateway log that seems to suggest the WAN interface is the issue. Comcast is my ISP, and I own my own cable modem (Netgear CM700). My gateway {pfSense 2.5.2} is an old repurposed HP workstation with a 4-port intel NIC. I have been running pfSense for about two years. I have a fairly complex system with multiple LANs /VLans and a plethora of managed switches. It could be my cable modem that's on its last leg since it has a poor reputation (the controversial PUMA chipset) or my switches due to an improperly configured STP because sometimes the issue would be temporarily resolved after rebooting only the switches. However, the issue continues after properly configuring STP. Refreshing openvpn would also temporarily resolved the issue. Also quickly unplugging and plugging solely the WAN ethernet cable would temporarily resolved the problem. I'm currently at a lost for solutions. It wasn't until today when I finally really read the pfSense logs in details that pointed me to the potential culprit, the WAN interface. Before that, I tried all types of fruitless solutions. I serendipitously stumbled on your potential solution, changing the speed/duplex of the WAN interface from autoselect to 1000 base T full duplex. I have applied it and hope that it works; fingers crossed and will find out in a few days if this was the issue.

@stephenw10 Thank you, I will give that a shot. I appreciate the feedback.

One more expression of appreciation @stephenw10 : I'm getting consistent 150Mb/s+ IPSEC on this thing. It's a beast! Thanks again!!

Mmm, I agree looks to be configured the same in all cases.

Take a look at a HP t620plus thin client, it needs to be the plus model though not the t620. The t620plus is thicker than the non plus because it has a pcie port to add a network card. They are quad core 2.0ghz and use around 12-15w of power, you can find them on ebay for around £100. The link below has some good information on the t620plus. Link to parkytowers site

If you actually have a 10Gbps WAN link you would likely want something a lot more powerful to be able to fully use it. Or consider running TNSR instead of pfSense. Steve

@stephenw10 said in SFP+ 10G PCIE 3.0 x4: It looks like there are several reviews open for the tn40 driver but it isn't in FreeBSD yet and hence not in pfSense either. You might be able to make that work but you'd need to compile and install it yourself. I would just get an X520-DA2 or one of the OEM equivalents: https://forums.servethehome.com/index.php?threads/list-of-nics-and-their-equivalent-oem-parts.20974/ Steve Thanks, then it will be X520-DA2. Aleksander

@stephenw10 said in My guide to installing pfSense on Watchguard x750e: different com ports I see this : [image: 1648827176774-52e26d4a-ac08-44a2-9e93-bbf403d5ead5-image.png] and you see comm ports ?? edit : Oh wait, just zoomed into 400 % : I see comm ports .....

All the ports can be used as 'WANs' or 'LANs', they are simply labelled LAN on the case. Steve

The OPT interface there is linked at 100M which is why it only shows one LED. I assume it's connected to the TV still? I would physically inspect the port. We have seen pins get bent across by bad plugs or some other object being inserted. Sometimes the pins can simply be moved back. However if it is linked with 2 pairs only I would expect it to fail to pass at 1G when the AP is connected. Steve

If your device supports it, booting UEFI may also yield better results. the UEFI settings on the device may even have an option to set the terminal resolution which you could set to match the panel's native resolution. YMMV, though. That's all in the hardware, not the OS. The basic text console in the OS doesn't have any knowledge of video control at that level.

That's an ARM device so no, not without significant development work. Steve

Looks like it's an i225-LM so it should be supported: https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_6_0/sys/dev/igc/if_igc.c#L54 Steve

@dobby_ Thank you After the upgrade from 2.4.5 to 2.5.0 Im a bit shy. Just wrecked our OpenVPN setups here. We'll build a 2.6.x and test. Again I appreciate your input.

@daddygo This is an old post, but seeing that it is still unresolved, this may help: 1: If you are already running pfSense on your hardware (apu2xx, apu4xx etc), and want to know if you will be able to successfully boot from a particular USB drive (e.g. if you're about to do a format-reinstall--new drive, ZFS etc.): Plug in the USB drive with the system running. Watch the console or dmesg. If the OS immediately sees the device, you'll be able to boot/reinstall without any problem. e.g. [2.6.0-RELEASE][root@pfSense.home.arpa]/root: ugen0.2: <Generic Mass Storage> at usbus0 umass0 on uhub1 umass0: <Generic Mass Storage, class 0/0, rev 2.00/1.00, addr 1> on usbus0 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: <Generic Flash Disk 8.07> Removable Direct Access SPC-2 SCSI device da0: Serial Number 60124D45 da0: 40.000MB/s transfers da0: 7680MB (15728640 512 byte sectors) da0: quirks=0x2<NO_6_BYTE> On the other hand, if it takes a long time before the USB drive shows up with da# (or times out), the you will want to maybe NOT blow away your current working install (until you can your paws on USB drive that plays nicely with your OS & BIOS). e.g. [2.6.0-RELEASE][root@pfSense.home.arpa]/root: ugen0.2: <SanDisk Cruzer Fit> at usbus0 umass0 on uhub0 umass0: <SanDisk Cruzer Fit, class 0/0, rev 2.00/1.00, addr 1> on usbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted 2 We've tried a bunch of USB drives, and all of the USB 2.0 devices that show up as "Generic Mass Storage" have worked reliably. e.g. the cr@p USB drives you get for free in a box of cereal, or from a trade show with some vendor's name embossed on it. NOT the name-brand Muskin, Lexar, Sandisk etc. 3 This issue appears to be at the intersection of FreeBSD, and this particular BIOS/Hardware (and possibly the front-facing ports too). We have booted dozens of different versions of these APU boards using all manner of 'problem' drives without issue when booting to TinyCore or Ubuntu. I hope this helps.

@n1ck31 (X710-T2L) Some peoples where reporting they where running out of the box (installing 2.6 and update to 22.05.2) and some were flashing new firmware, on it. (version 9.1xx) to reaching their goal.

Hi together, All are plugged into the same 10GbE switch and the two Linux boxes can client / server using iperf3 at 10GbE speeds. As @bmeeks was answering, test it through the pfSense and not from or to it. Routers are connecting one or more networks and firewalls are separating one or more networks using rules. And pending on the rule set it is narrowing down step by step with any new rule and/or installed service (packet) like snort or other it will be using more cpu and electric power to hold that line speed. And on top of all the switch is perhaps layer2 and this is faster than routing in layer3, please don´t forget it. Tweaking or tuning adapters will be here and there more pending on the entire art of network traffic. Sometimes you get success if you narrow down numbers (mbuf) or disable something and sometimes you high up that numbers or activate some different points to get your wished result. So it is not so easy to say do this or that, it is more pending on each single use case as I was getting it out here often in the forum.

@deridiot said in Weird Behavior with x710-da2 in 2.5.x: Issue still present on below build, resolved with the same change mentioned above. 2.7.0-DEVELOPMENT (amd64) built on Fri Feb 04 19:41:27 UTC 2022 FreeBSD 12.3-STABLE Installing 2.6 and update to 21.05.2 was solving that problem for a X710-T2 adapter, so perhaps it could work for you too.

@fireodo ok. i'll bite the bullet and try it. I have tried disabling all interfaces and services and bring them back and definitely, irrespective of the heat sink, pfBlockerNG makes the temprature rise by at least 5deg