@grimmsh0t said in PFSense Build - New to PFsense: seems my home lab is always changing so its a constant money pit. Well lab are yeah money pits ;) Not all that bad for "lab" use when your going to turn on the stuff here and there to lab something.. But 24/7 is not a "lab" ;) See all the time elsewhere where "labs" are a subject -- that is not a lab.. That is your network, and your tinkering with it.. .Sorry but something that is on 24/7 and use every day for file storage and other things like plex and whatever - is not a lab ;) Its your network.. And neither is your soho router and a raspberry pi - hehehe To me a lab is something doesn't matter if on or off, has no effect on your normal network.. Wife has no clue if your lab is on or off.. You could blow it up from a config standpoint, and your normal network users wouldn't have a clue.. Then its a lab.. If your tinkering around and wife screams hey what happened to the internet, good hint its not a "lab" ;) Now you can lab stuff on your network ;) But if someone could scream hey X not working where your doing it.. Its not a lab - hehehe.

Which console are you using? The configs on that site do not have the serial console enabled so you will see nothing after root is mounted at boot if you're looking there. Those configs have a bridge which is generally a bad idea. But additionally it is configured badly for that type of setup. The IP and DHCP server is on the LAN interface rather than on the bridge interface itself. That means that if you connect a device to the OPT ports and do not have the LAN connected it will fail. It's configured to send all your traffic via the VPN so the available bandwidth will be dependent on the VPN speed which could be limited by either the provider or the CPU in the firewall. Steve

@steveits, Currently, I have not so speedy DSL and the VPN is used exclusively by me in one of two circumstances: I am on a public WiFi and I wish to ensure treatment of my data such that it is fully encrypted or I am not at my home and wish to access resources (my file server, a Linux system I need to test something on, scripts I have that I use with customers from time to time, etc...) So for me, encryption speed is currently not an issue, however, I can see where it would also be a consideration when my internet choices are higher speed connectivity too, as why let software based encryption frustrate the higher internet speed you might have and one day i might have? After all, I do not regret having DSL instead of accessing the internet with a Hayes 300 modem! My first thought was why force people to have AES-NI hardware if pfSense can be designed to not need it or to make the AES-NI portions of pfSense "pluggable"? However, in succession to further consideration I realized that Intel will eventually sell no chips without AES-NI (if they have not stopped selling chips without AES-NI already) and after the passage of more time the only "older hardware" will all have AES-NI based chips in it. At that juncture the point of if AES-NI is required or not will be as moot as anyone being concerned if pfSense can run on an Apple II, TRS-80, or Commodore PET. Thus, I realize that the only intelligent choice is to plan on purchasing hardware that either has AES-NI built in, or expect the lifetime of hardware not supporting AES-NI to be short lived. Clearly, no one will just keep running the last version of pfSense to work on non AES-NI hardware, as why have a firewall if the software it is out of date? The very fact that my DSL modem, made by Zyxel, has NEVER had a firmware update produced in over 3 years is precisely why I run it in bridge mode and have a firewall (currently Gargoyle, my open source router firmware does this for me). Given that Gargoyle does not support 802.11r/k/v/w and I want to use those technologies, I am going to migrate to OpenWRT for router firmware. Part of that migration I plan is to use a pfSense instance as my actual internet facing router, whilst my OpenWRT based APs will move onto my LAN and be facing the DSL modem as one AP does now. In closing, I must admit that your comments did force me to think more deeply about this issue and to conclude that the future is surely hardware ensconced encryption. Thank you again and do have a most happy, healthy, blessed, and safe/thug-free holiday season.

Yeah, you should be able to restore a 2.4.5 config from a 3100 directly into a 6100. It doesn't hurt to upgrade the 3100 to 21.05.2 first and backup the config from there though. The only hurdle you're likely to face there is if you have separated any of the switch ports (LAN1-4) on the 3100 using VLANs. Since there is no switch on the 6100 all the ports are discrete NICs and no VLANs are required. However I would still expect it to be simply a matter of re-assigning the interfaces in the webgui before rebooting into the new config. Steve

@stephenw10 Thanks it worked

@sergei_shablovsky said in [SOLVED] Errors In, but no Errors Out and No Collisions on both WAN: Of course, our rules would be Using for copper link as much quality as available from local distributor. Because You make cabling one time in 2-3-5-8 years, up to the next applience upgrade ;) That is a very good rule. Even for your home network.

In the end I went with Dell Wyse 5070 Extended. I also put Dell 09YD6K 4-Port 1 Gbps Ethernet NIC inside. That is Intel i350-T4 card. I had problems with this card cause when I put it inside, dell was not posting anymore. It signaled memory problem. So if anyone has similar problem with i350 card, solution is to block pins B5 and B6 with electric tape. After that it posted and everything works ok. Solution was found here: Modding a Dell Perc 6 / Dell H310 / Dell H710 (other LSI 1078 or 9223-8i based) SAS Raidcontroller. In comments on that blog post, someone mentioned i350 NIC.

Mmm, well I would definitely try booting verbose to check the ACPI errors if you're seeing this as I said previously. There's a good chance the BIOS is passing some values to FreeBSD that Windows never sees because most manufacturers don't care about anything else. Steve

Ah, yes. Well it might work. Unfortunately we have no way test so I cannot be sure. There have been a few threads about it here but I don't think anyone have actually tested it yet. Steve

@cybermancer Hy cybermancer i'm in this case to. Could you explain your operating mode for the script?

@stephenw10 said in iwifw() module loading show ERROR in dmesg, if it needed on server ?: It's already not loading them. You can see they are not listed in your kldstat output. Adding those lines to loader.conf won't change anything. They are loader variables you have to add them there, adding them as sysctls does nothing. You are only seeing those lines at all because you're booting verbose. Thank You Steve (and all others here!) for patience and help with this case. Have a nice day!

The i350 NIC has better potential throughput since it presents 4 queues per NIC and the i211 only 2. However the difference is marginal. I would expect either to be able to move traffic at Gigabit line rate given a sufficient CPU. Steve

@stephenw10 Thanks, i will check there.

@jimp said in How to set different certain screen resolution on FreeBSD and pfSense boot for VGA and COM Console output ?: The monitor size doesn't matter. It's a matter of being able to drive the video card appropriately, which in many cases isn't possible. Some VESA modes may work but mostly you have to worry about dumb things like video drivers consuming memory and kernel resources better spent on firewall tasks. Thank You again one time for suggestion. From this point of view where better to place the settings for screen resolution (/boot/loader.conf, /boot/loader.conf.local, Advanced / System Tunables) to not losing settings after pfSense system update?

There's no way to change that behaviour as far as I know. I have looked into it a few times in the past and nothing I have tried had any effect. There is no ACPI power button on the XTM8 so you would still need to power cycle it to boot again anyway. Unless you added one. Steve

You should only have that one line in loader.conf.local because that will take preference over loader.conf. So if you change anything in pfSense that requires updating loader.conf it will not work if you have all the old settings in the .local file. For LCDproc I use: [image: 1635345253933-screenshot-from-2021-10-27-15-33-12.png] [image: 1635345261784-screenshot-from-2021-10-27-15-33-35.png] The screensize and port settings are hard coded into the SDEC driver so it doesn't actually matter what you set there. Obviously the choice of screens to display is up to you but those work well for me. Steve

@c_c said in Supported and working external Gigabit NIC: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210488 Ah, interesting, Do you see the very high error rate when flow control is not enabled?

@rmeskill Thank you for the responce. I have Done the same now.. and i hope the huawei model i bought today will work better :)

It's x86-64. VK-T40E was our internal name for APU(1) sold through the pfSense store. The CPU is an AMD G-T40E. It's this: https://www.pcengines.ch/apu1d4.htm I would certainly expect it to run OpenBSD if that's what you need. What's the actual error you see? Does it still boot pfSense correctly? Try the memstick serial image: https://nyifiles.netgate.com/mirror/downloads/pfSense-CE-memstick-serial-2.5.2-RELEASE-amd64.img.gz Steve