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

Problem fixed by forcing the gateway on the AP to PfSense's LAN IP. I had it set up through /etc/network/interfaces but turns out I had to set it up via route add default gw 192.168.1.1 wlan0

Ok tomorrow morning I work on it a little bit following that thread, for the moment I had to esculede Pfsense, if in case I can't solve it quickly I will downgrade to version 5.2.2 Vince

That's just down to how you have it setup in VBox. You want the WAN side NIC passed through to the pfSense VM WAN interface so it cannot connect to anything without the firewall. The LAN interface can be bridged to NIC2 so anything there will see it on the same subnet. Including the host. You don't want the host PC trying to use DHCP to pull an IP from the pfSense though because it obviously won't be able to until the pfSense VM has booted. So set the workstation to a static IP in the LAN subnet but outside the DHCP range. Steve

I've had a lot of problems with Hyper-V virtualizing firewall, the performance of Endian Firewall on it is poor, as well as problems with pfSense and other things. The ones I had the best results were VMWare and Proxmox, but since I hate VMWare (personal taste), Proxmox became my main virtualization tool! Nowadays with Proxmox Backup Server and the great adoption of KVM by several market players over proprietary solutions, after Citrix mistakes about XenServer, Proxmox has become even better!