@stephenw10 hahah, but its good... I believe this comment could be considered as covering the no route problem, or wrong route "what your pinging either sending its answer to somewhere else" But I like the clarity of making sure route is there to send it to back to pfsense.. Will keep that in mind for next thread we get about such an issue. Which I know there will be, since it is a common question to be honest ;)

What error do you see when you try a DNS Lookup? Are clients using pfSense for DNS? Is Unbound running?

@markdudov said in WAN packetloss: @stephenw10 In what cases are the gateways dropping ping requests? Also in case for example, when You have Your ISP's device (mediaconvertor-router) ETH up, and assigned IP by ISP's DHCP, BUT PACKETS BLOCKED on ISP's core level.

That should be fine. And, just to be clear, I would have expected what you did before to also be fine. pkg shows that it sees that as an upgrade and takes appropriate action. It shouldn't be possible to have two versions on the same pkg installed.

@stephenw10 Ok. thanks

Also I checked my plus. It is appropriate version on plus. And no, this isn't holding out stuff for paying customers and shafting the community...cert token auth is generally an organization that should be paying the license fee anyway. Home users just plain don't do that very often... nor is it exploitable reasonably. Same with the system names thing. This is a rare thing...even more rare in non professional roles.

@markdudov so you want to generate a key for the ntp server on pfsense so your clients can auth? Not sure pfsense has support for that option, pretty sure the ntp auth they have available is for pfsense to auth to some ntp server as a client. "Authentication allows the NTP client to confirm it is communicating with the intended server, which protects against man-in-the-middle attacks." And I don't believe they allow for talking to more than 1 ntp server with different keys either.. Maybe in 24.03 or I know there is some patch or working on a patch for ntp auth. Personally I don't understand the use case for auth for local ntp.. You concerned that there will be some rogue ntp server on your network and you need to make sure your talking to the correct one via auth? Or that only your own clients on your own network are validated via auth to your server? Seems like extra work/config/setup for like zero benefit other than a complexity that could cause issues.. In what scenario on your own local secure network does this added complexity provide added anything? Is someone going to get on your own local network and fire up some ntp server to do mitm on your ntp traffic? For what purpose exactly? And how would they go about such a thing without having physical access or already compromised your wifi?

@skogs windows added ssh many years ago.. But they always seem to be behind last I looked. I always just install this openssh version https://www.mls-software.com/opensshd.html

@anotherguy82 Tons of people run pfsense virtualized on Proxmox and I think the most common setup is to have dedicated NIC's for both WAN and LAN. And the preferred setup is to do passthru (IOMMU) of those NICs so that pfsense is the only machine accessing them (giving optimal performance). So you assign two out of your four NIC's to pfsense and the others will be available to Proxmox and your VM's. Nothing other than pfsense WAN is exposed to the internet. You have to make sure virtualization is enabled in the Optiplex BIOS to make this work though. On the topic of VLAN's, yes your TP-Link Layer 2 switch will support that perfectly fine.

But also if you have set the webgui to run on a different port, say 43434, it will redirect to that. http://pfsenseip => https://pfsenseip:43434

True. I guess I should specify, when using the default values or DHCP. My test setup has more hosts than that and is served by a 3100. I never see any DNS issues.

Both those things should be a feature request in redmine if there is not something existing: https://redmine.pfsense.org/

I'm down to the one problem that IPV6 doesn't work. I can see the DHCP6 request sent over the WAN interface and the /60 PA returned. However, these neer get assigned to interfaces. Also, the router sends a seperate DHCP6 requst for the WAN interface (because the instructions do not selecet "Request only an IPv6 prefix"). ATT assigns an IP address that is completly different than the PA assigned and regardless it is not assigned to the WAN interface. We should be taking the first prefix ID (for example prefix ID 0) and using it for the WAN interface IPV6 address. Any further ideas. I suspect there is more configuration required for IPV6 that is not in the guide. IPV4 and everything else seems to work. Have WAN DHCP6 PCAP.

I don't recall the exact command but it was something like usbconfig -i ugen0.2 detach_kernel_driver

Yes, it needs improvement. There is currently no way to configure what triggers a notice though. There are open feature requests you can add a comment to. https://redmine.pfsense.org/ Steve

Opened bug report: https://redmine.pfsense.org/issues/15547 Appears to be mostly cosmetic though.