@viragomann said in CPU Thermal Sensor Info: Sensor reading need direct hardware access and for my understanding this is not given. Thank you for sharing. @Patch said in CPU Thermal Sensor Info: I think this is a Proxmox limitation Wow, I am not alone seeking this vital info...thank you Patch!

Since no further details have come to light, I have created a new bug in redmine: https://redmine.pfsense.org/issues/14450

@vnoob said in PFsense not routing between lan and wan: maybe that wasn't the best info to provide as that machine also has a dual nic with one in each network and I was pinging out the lan network on it. In fact. Packets will go the shortest path and you will end up in asymmetric routing issues. But pinging from the WAN interface to a lan IP fails... As far as I can tell, this is not representative. Packets are sent out on the WAN for whatever reason. You can use any other internal interface address. However, your LAN device might block this with default settings. You can sniff the traffic on the LAN while doing this to see, what's going on. so I am not sure what I am missing. Me too. Just try an outbound connection from a device behind pfSense, while you sniff the traffic on pfSense LAN and WAN to investigate this.

@korr2221 I think you’re looking for https://docs.netgate.com/pfsense/en/latest/backup/restore.html#restoring-by-mounting-the-disk but it doesn’t have many details except to use FreeBSD (on which pfSense is based).

What version of VMware are you using? There was an incompatibility problem between newer FreeBSD versions and earlier versions of ESXi (such as the 5.x series) when using the VMXNET3 adapter. That problem was resolved for me by updating to the 6.x ESXi version series. I am currently running 6.7-U3 because of limitations with my host hardware. pfSense 2.6 CE uses FreeBSD 12.3-STABLE. pfSense 2.7 CE Snapshots and pfSense Plus 23.05 are both running on FreeBSD 14.0-CURRENT. If you are running an older VMware version, I suggest updating to the most recent version and also making sure your VM tools software client is current on the pfSense virtual machine.

As a last ditched effort, we tried upgrading to the development version of Pfsense (v2.7) and so far the issue is resolved. Now the question remains, do we go and turn on RSC and LSO so we are back to default on the hyper-v host?

Finally got it running and recognizing the WAN. I deleted the EFI disk and it finally booted decent-ish. froze at the same screen, but if i goto boot environment, cycle through the 3 options, then hit escape and press 1 to boot to multi user, it boots fine sooo, no idea whats going on there. As soon as i re-add the EFI disk, it shits the bed again. doing the fsck command in single user still does not work either...

@stephenw10 I can confirm just like @hendryjl that this happens VM to VM in the same host or across Hyper-V hosts. Disabling RSC in the vSwitch fixed the issue I was having with pfSense 2.6.0. I didn't want to update to 2.7_devel branch, and didn't want to go back to 2.5.2. Will wait for 2.7 CE to be officially released and test again.

@gusto Very interesting question, indeed. The thing with VM is its dependence on the host. So, with tools such as qemu agent, maybe.

@dobby_ there are no official packages for hyper-v..there are for vmware..which i am not using. The tools are enabled under hyper-v. this is a long standing issue under hyper-v 2019 and i have tried the fixes there on 2022 to no avail. I have seen no system package to address this under hyper-v 2022 that i can see. if you know of some individual patches if you could pint me to it i would be happy to try it..:) I also noticed 23.05 is released but no mention of addressing this issue under 2019 or 2022 hvper-v int he latest release notes.

@johnpoz with or without SR-IOV? Maybe you're asking for both scenarios, but in the case with SR-IOV I don't even know if it's worth testing with what I'm able to tell at this point...

@johnpoz Patch (@Patch) was kind enough to make a manual instructions here: https://forum.netgate.com/topic/162083/pfsense-vm-on-proxmox-qemu-agent-installation/27

I have sucessfully added one more interface. Couple of reboots and it resolved the issue. Will try to do 1:1 NAT and update the status here.

@thebigbear We did not work on routing. This should work out of the box. Our backup is working now. But the waagent is not in a perfect condition for freebsd as mentioned... [image: 1683566932869-4bc02d28-050a-4b3c-a904-8753c4d80f9a-image.png]

Now, I got it right without the need to disable any firewall...my mistake was to move default gateway to pfSense. The default gateway is just for Proxmox management port to update itself and need to remain on the port originally assigned. Then, I made pfSense LAN that IP. Both accessible by my Mac Pro on the same browser tabs next to each other. [image: 1683404300480-screenshot-2023-05-06-at-3.14.07-pm.png]

Thank you, I will try. Sam

@bmeeks Ahh, yeah, I'm using N5105 so this is almost certainly it. I'll keep an eye over there, but I guess there's no solution yet...

@dobby_ I think I might have narrowed it down to an issue with the Intel I226-V ethernet controllers my mini PC has. Ended up disabling the offloading options within the driver settings- IPv4 Checksum Offload Large Send Offload V2 (IPv4) Large Send Offload V2 (IPv6) TCP Checksum Offload (IPv4) TCP Checksum Offload (IPv6) UDP Checksum Offload (IPv4) UDP Checksum Offload (IPv6) The issue hasn't came back yet, so hopefully that might be it fixed. found the potential fix here Thanks, Gary

@jk-1 I found the problem, for whatever reason (probably self-inflicted) the subnet mask on the VLANs that did not work was set to 32...

Well, persistence paid off...the key is to start hitting the ESC key before clicking start . [image: 1681184506988-screen-shot-2023-04-10-at-10.31.23-pm.png] [image: 1681184534882-screen-shot-2023-04-10-at-10.35.20-pm.png]