@basense Can you check out if it's an DNS issue? Try to ping a public IP, e.g. 8.8.8.8. If that fails as well, is pfSense able to access the internet? If not, it might rather be an issue or wrong settings in VirtualBox.

@topogigio I have no idea about the hw upgrade or VMware. But always backup the config file to a secure place ... Then it's easy to reinstall pfSense , to the current state - If s... hits the fan. /Bingo

Well, since the test is with the host, and pfsense is not involved, why it is a pfsense issue. The host connects to the internet through the pfSense VM.

@gertjan Ah, brilliant, that did the trick. Many thanks! :)

Actually solved using gpart instead of fdisk (this way I can see and manage the disks). Thank you.

@gdzbedfz You should start with troubleshooting where the problem lies. Run a tcpdump on the interface you're sending the PFSense logs to. If you see Syslog, then you know the issue lies within the Elk configuration. If you don't see the logs running tcpdump, you have an issue blocking PfSense syslog from reaching Elk.

You will need to set the virtual network adapter(s) to trunk mode, see Set-VMNetworkAdapterVlan If you have more than one vmnetworkadapter you can filter by macaddress, for example: Get-VMNetworkAdapter -VMName "vmname" | Where-Object {$_.MacAddress -eq "00155D010203"} | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "2-9" -NativeVlanId 0

@stephenw10 Oh wow. I misunderstood. Assumed this was the NIC detaching because the whole bus shouldn't be possible, as you said. I need to dig into the Hyper-V side of this to understand that. That's absolutely baffling behavior. But hey, Microsoft...

@bob-dig Potentially; without packages I don't think I've seen a router over about 2-2.5 GB actual usage. Remember to allow space for OS+pfSense upgrades, runaway logs, etc.

Mmm, I'd expect that to 'just work'. Seems like a proxmox issue though. Can we see you proxmox network config?

@rcoleman-netgate Dear Readers, This issue is now solved for me. Here's an explanation for future vmware fusion folks... I redid option 2 again for the LAN interface, noting that the bridge100 interface on in the MacOS offered up the 192.168.198.0/24 network (see above, your bridge networks may be different). I entered in for option 2: new LAN ipv4 address: 192.168.198.10 (198.1 will not work) subnet mask: /24 (class C to match the bridge100 interface) enable DHCP server start address of range: the IP number you used above, eg 192.168.198.10 end address of range: some higher number in the 4th octet, eg 192.168.198.200 yes or no to the http setting Important in VMware! After redoing the LAN interface, then go into the vmware configuration for the LAN network interface (compare the MAC address via the pfSense shell to your interface). ==> Change the interface setting from "Share with my Mac" to "Private to my Mac". Let vmware make the changes. At this point, your pfSense network setup should look like: WAN (wan) -> em0 -> v4/DHCP4: 172.16.20.138/24 LAN (lan) -> em1 -> v4: 192.168.198.10/24 and you should be able to ssh or https to IP number 192.168.198.10 to login or see the pfSense webpage.

I reverted to the snapshot, upgraded the virtual hardware (6.7 compatible) for the VM in ESXi and did the upgrade again. This time it worked.

While that is true that a userland program should not be able to trigger a kernel panic, pimd should still ignore interfaces that don't exist. One doesn't absolve the other of having a bug in this case, they are both doing something they shouldn't.

Mmm, that seems expected. Opyion 6 form the menu would be shutdown -p now. '-h' just halts and seemingly fails to reboot like a normal reboot does. The reroot option doesn't reload the kernel etc so doesn't touch any ACPI power functions. I would expect that to work. Steve

@urbaman75 said in PfSense with ZFS RAID1 on Proxmox Ceph pool: Is it OK to make the pfSense instances RAID1 zfs? Or is it better to use UFS in this scope? Hi, If you listen me, then definitely ZFS