@sand7000 In my case, I always test and try to exploit every 1 of the published vulnerabilities to confirm for myself that they are not applicable Until now, it has been shown to be very, very reliable.

OK...I'm stopping. Apparently the pfBlocker VIP and Web Server Interface ports were "sticking" and after several changes and Force Updates I got the DNSBL Webserver ports to change to 80 and 443 on localhost and set the VIP from 10.10.10.1 to 192.168.254.254. Everything seems to be working... NTP with localhost and not WAN selected syncs, Avahi is happy (that was a red herring), and pfBlocker is working. It all seems to come down to, for some reason that I don't know, on this firewall NTP binds to the VIP because it is lower, where as on the SG-5100 NTP ignores the VIP even though it is also lower. Thank you for your patience and all of the assistance. Edit: I figured out why the SG-5100 works... It has a VPN server at 10.3.x.x, BELOW the DNSBL VIP of 10.10.10.1. Whereas the VP2410 VPN is at 10.42.x.x, ABOVE the DNSBL IP. This was the difference all along and it is the VPN IP that NTP is now syncing to on both systems.

@stephenw10 Thanks for clarifying. I found no mention of the red blinking anywhere, probably not looking at the right place. It was easy enough to fix with excellent help from TAC Lite support. A few fsck did the trick. I will be more careful of how I use the reset button from now on, always initiating from within pfSense when at all possible... :)

@stephenw10 Maybe spoke to soon, another test or few now a 'D' or 'F' with nothing changed. As you mentioned I think it needs a bit of fine tuning especially with the bandwidth settings

@brundle said in Change SSH shell: OK. The admin account has the same UID and GID as root in /etc/passwd. Am I right to assume that it has the same privileges? Yes, they do, they are equivalent, but have some (necessary) differences in how they act at the OS level. The admin account is locked into the menu for its shell, root is not. The root account starts the menu at login but isn't locked to it in the same way. This is important for the console autologin process. I don't want to have to create public/private keys for the admin account to put on every system I have, instead I would like to use my regular user account and my regular private key. Once logged in I want the exact same behaviour and privileges as for the admin account. Is this possible? Only by using sudo as with any other *nix system. This isn't a special case, it works like any other BSD/Linux/whatever server. You could put your existing keys into the admin account in the GUI and just ssh into that if you like (it would work for root@ and admin@) though it is better to use your own account if you're already used to that. You still have to setup the account and keys in the GUI, though. I'm considering just copying the UID, GID and Shell fields from the admin line of /etc/passwd, but I worry that might break something. Any advise? That won't persist without editing the source to control how the accounts are generated, and is completely unnecessary.

That install has a file system issue but unless there is something on it you need I would just install 21.05.2 clean. Instructions for doing so are here: https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/reinstall-pfsense.html You need the specific 3100 image though so if you don't have that open a ticket to request it: https://www.netgate.com/tac-support-request Steve

Thanks for the reply Steven. Yes that is the hack I was referring to. Good to know it is not a concern in pfSense. Sorry for the newbie "BSD" reference.

@stephenw10 said in Footprint of Old Box in New Box?: I would also remove the MAC spoofing since that is doing nothing. Okay, will do that also, thanks.

i already was thinking of the SD card... but there was a little hope ;) the new msata ssd is already ordered. and now i'm hopping the SD give its best for the next 2 weeks. these pfsense is over 4h away from my home and i have no time to go there... thanks to all

I updated again without the traffic shaping and all is working ok! I really like the TS to manage my bandwidth! I don't see any improvement on the issues! Will this be solved? Tks

I assume you actually mean how many connections? That depends on the hardware and available WAN bandwidth. There is no artificially imposed limit though. Steve

@captncrypto941 Never set this up. So you don't need any authentication? If not, I think, it should work by selecting DHCP type. Simply give it a try.

Ah, nice! I guess there was some remnant of the static route you added somewhere. I don't see it in the table though. Weird. Everything there looks good to me otherwise. Steve

End-to-end encryption is most definitely diminishing the importance of IDS/IPS. And encrypted payloads can be the source of many false positives. The random encrypted data will occasionally match up with the tested bytes in a rule. There is also the issue of some admins misunderstanding the intent of some rules. For example, there are categories in both Snort and Suricata where the rules are designed to simply detect malformed network traffic. Not all malformed traffic is nefarious. It may just be the result of bad or inexperienced programming on the part of a developer. Some is the result of asymmetrical routing. So rules that detect this type of traffic are really for "information" purposes and do not necessarily belong in the block or drop action list. They usually should be left at ALERT and not elevated to DROP (or block if using Legacy Mode). False positives are the biggest pain with an IDS/IPS. Tracking those down can take a lot of work. In the old days, IDS/IPS was extremely useful. This was especially true when it could peer into the packet payloads. Also, back then, raw traffic rates were typically lower (granted so was CPU horsepower, but you still generally had more CPU power than Internet bandwidth back then). But now looking into payloads is usually not possible unless you use MITM. And 10G Internet traffic can cause even a powerful CPU to sweat bullets when trying to inspect that traffic against several thousand IDS rules.

@nollipfsense After installing NUT and then configuring NUT it all worked after Pfsense was rebooted. The key was to reboot Pfsense. Thanks for the help!!

@zwiebelspaetzle Mobile could be IPv6, could be a different web server entirely as they have multiple IPv4s. https://www.ssllabs.com/ssltest/analyze.html?d=www.podtrac.com&s=44.239.236.149&hideResults=on&latest looks pretty good but does show "Chain issues Incorrect order, Contains anchor". If the client had an issue with that, I would expect it to be a problem regardless of connection...but again could be different web servers.

@nollipfsense great - glad you got it sorted!

@idiotzoo said in Wan failover doesn’t work and bigger problems: Just the WAN failover to do some more testing with. Hello! All of my multi wan failover configs running on 21.05.2 cratered due to this: https://redmine.pfsense.org/issues/11570 I manually reverted this code change from this issue to get it working again. John

In a single WAN setup disabling the monitoring action is an acceptable solution. The gateway monitoring allows you to tune the latency and loss levels to match your WAN though. You should should be able to set levels that are not triggered in normal use but still do trigger if it actually goes down. The ISP supplied gateway does not have to respond to ping at all. And it if does it doesn't have to prioritise it. It's not that unusual to see the gateway drop pings when it's under load but still route traffic just fine. A lot of devices like that would have separate control and data planes and it's the control plane which would usually have to respond to pings to it's own IP. Setting a monitoring IP as some external site also gives you a much better idea of the actual state of your connectivity. Monitoring the gateway wouldn't show an outage at the ISP but upstream of the gateway for example. Steve

Thanks for your answers, very informative.