For future reference I made a summarized the all the information possibly required: My setup: Proxmox version: 8.1.4 pfSense version: 2.7.2 NIC: i340-t4, i219 (motherboard) Network configuration: vmbr0 is assigned to LAN in pfsense and all other VMs in proxmox, it also has slaved physical port (i340-t4) that connects to rest of the lan vmbr1 is assigned to WAN in pfsense and it has slaved physical port (i340-t4) to ISP1(DHCP) vmbr2 is assigned to WAN2 in pfsense and it has slaved physical port (i340-t4) to ISP2(PPPoE) vmbr4 is assigned for proxmox management/cluster only and it has slaved physical port (i219) that connects to same physical switch as vmbr0/rest of the lan The issue: Port forwarding works when using NIC passthrough, but not when using virtIO Specifically, port forwarding doesn't work for the DHCP ISP connection when using virtIO, but does work with PPPoE ISP2 I have tried: disable hardware offloading in pfsense ethtool -K XXXX rx off tx off for physical ports as well as vmbr(0-4) on proxmox manually changing MAC Addresses on vmbr(0-4) in case there would be a conflict, especially vmbr1 having same MAC as the physical interface This is my /etc/network/interfaces with manual MAC Addresses, to test without that I just comment out the vmbr hwaddress lines: auto lo iface lo inet loopback auto enp1s0f2 iface enp1s0f2 inet manual iface enp1s0f3 inet manual iface enp1s0f0 inet manual hwaddress XXXXXXXXXX iface enp1s0f1 inet manual iface eno1 inet manual auto vmbr0 iface vmbr0 inet manual bridge-ports enp1s0f3 bridge-stp off bridge-fd 0 hwaddress 90:e2:ba:37:0d:a0 #LAN auto vmbr1 iface vmbr1 inet manual bridge-ports enp1s0f0 bridge-stp off bridge-fd 0 hwaddress 90:e2:ba:37:0d:a1 #Antik auto vmbr2 iface vmbr2 inet manual bridge-ports enp1s0f1 bridge-stp off bridge-fd 0 hwaddress 90:e2:ba:37:0d:a2 #Telekom auto vmbr4 iface vmbr4 inet static address 192.168.0.70/16 gateway 192.168.0.1 bridge-ports eno1 bridge-stp off bridge-fd 0 hwaddress 50:65:f3:48:34:a4 #PVE

@Patch I hadn't considered it could be to do with my switch. I have a 10-port Zyxel switch. I'll consider that when I do my troubleshooting. For clarity, I have 2 NICs passed-through to the VM, one for LAN, one for WAN. I use the Mgt interface on the host for everything else.

@planedrop said in Need Help Resolving VLAN Errors OUT (Interface Statistics) on a Hyper-v Virtualized pfSense: s this a brand new setup or has it been fine for a while and just started having this issue? (maybe after an update, pfSense or otherwise like the host) Just double checking that, with TCP segmentation offloading things should work pretty well. I've never used pfSense on Hyper-V (despite having a lot of Hyper-V experience) so I may not be the best resource here but will see if I can come up with any issues. Is they Hyper-V host a Win Server OS or Windows 10/11? Good morning, I actually did a clean install in 2.7.2 when the version was released. In version 2.6, I didn't seem to have this problem. Regarding Windows updates, there are so many and I do them regularly. Thank you very much for the feedback. It's a hyper-v on Windows Server 2022. I tried with a fresh installation of PFSENSE 2.6, but I have the same problem.

@miracuru As was mentioned by @viragomann the "Default deny rule IPv(4|6)" logs are normal. Actually they show that pfSense is doing its basic job, which is (by default) blocking all incoming connections to WAN. You could implement a firewall rule on the WAN interface which does the same thing, but doesn't log the blocks. Enable that rule when you don't want pfSense to record all the WAN blocks in the logs. If you want to start logging the WAN blocks, just disable your rule and the defaults will kick in again. Also, it may be possible to directly connect the enpf4s0 and enpf7s0 interfaces to pfSense via PCI-Passthrough. This will depend on hardware compatibility, but could be worth looking into; just food for thought.

@lonblu said in PFSense loses connectivity with more than 4 interfaces: @headhunter_unit23 Still Happens in 2024 on esx 8.1 and 3 months old month pfsense install. when I added a 4th interface everything went down and had to reassign the interfaces from console and lost all nat configuration. Very weird. My Wan was vmx0 and all of a sudden is vmx1 (unless is the only one). To be sure I had to configure the dhcp servers on each if and switch connection to find out what ip my machine was getting. Licensing might be a good guess still because I just updated the esx trial version. It's a known behavior of ESX and how it probes interfaces. See https://forum.netgate.com/post/687896 for some more info There are allegedly some ways to work around that but it's ultimately an issue that vmware needs to solve in its hardware emulation.

As you’re using Thick Provisioning, I take your using iSCSI and not NFS? Are other Virtual Machines suffering with the same issue? Normal on bare metal it would either be a bad cable, drive or bad controller even bad Power Supply. Since you’re virtualising pfsense I would look at what you’ve configured the Virtual Drive to even try a backup and restore. Or test a fresh install on a new VM.

@tibere86 Please create a new post for your question. Thanks.

@Popolou thanks. It's done. All working perfect.

How to configure this to work. I'm trying to do the same, but my success tends to zero. I created two separate port groups (one for Wan and one for LAN-trunk mode). When I migrate PFsense nics to DVswitch all connections die.

@viragomann said in pfSense on Proxmox via vmbr0 - got LAN access, but no WAN/internet access - why?: @newsboost You cannot use a passed-through NIC on Proxmox itself. The only available NIC you can use is enp1s0f3. That makes completely sense to me and probably explains the error message, thanks! But I'm really confused now, because it seem to work, i.e. it provides VLAN 100 internet access and yet it seems that the interface is still being passed through, because enp1s0f0 = igb0 = WAN and enp1s0f1 = LAN (vlan trunk) = igb1... Are you sure this should not work, because it seem to work? And why does it work, is it kind of "undefined behaviour" perhaps? Great comment, thanks! That's not a prlausible reason to have two subnets on Proxmox. The explanation was not good enough... So, VLAN 1 (subnet 192.168.1.0/24) is my management VLAN and the VMs I create in Proxmox should preferably not have access to the management VLAN so I thought the safest and quickest solution would be to use another subnet for all my experimental VMs... That way, they don't have access to the more important devices/machines/printers/servers on VLAN 1... I think this is a better explanation, hopefully... Just connect the bridge vmbr0 to a physical NIC port and assign a static (!) IP to the bridge in Proxmox. This should be a trusted subnet of course. You're right - and I did just that and it also works: [image: 1702412034450-209a52c4-6261-487e-9fff-3645ceca5665-image.png] From a logical perspective, this makes much more sense because as you wrote above and after I've been thinking about it, I think it's weird that I can bridge a NIC that has been passed through to proxmox and still get the behaviour that I wanted - but after my improved understanding and after reading your comment, now I wouldn't expect this to work any longer, but it still does... Very weird, it can bridge the NIC when passed through, apparently without internet/network problems! So to access Proxmox in case of emergency, you have only to assign a static IP within the same subnet to a computer and connect it to the appropriate network port. Then you can access Proxmox independently from the state of pfSense. It makes completely sense what you're writing and probably the solution could be that I should have two VMBR-interfaces: One for emergencies, if pfSense does not respond or boot up correctly so I can plugin a network cable and ssh directly into Proxmox and One on subnet 100, such that I can isolate all the VMs from the management VLAN and do experiments without any fear... Is it really that bad if I put vmbr0 in the VLAN 100-subnet so the proxmox interfaces can be access on two different subnets? Because I've been testing and it seems to work completely fine on two different subnets - although perhaps I would like to later block VLAN 100 from accessing the Proxmox-interface and I can do that by adding a firewall-rule using the pfSense-interface, isn't that right? Appreciate your comments a lot, thanks!

@eiger3970-0 Well I'm using a work around now with a remote access client and server. Bit confusing why I need a VPN or Tunnel, apart from security right? Even when a VPN or Tunnel is installed, I haven't been able to setup remote viewing, say with VNC and RealVNC on the phone.

@sknigen said in High CPU usage after upgrading to 2.7.1 Community Edition in XenServer: https://forum.netgate.com/topic/184245/high-interrupt-cpu-usage-in-v2-7-1/7 Ah, better to use that thread going forward then.

@sgw The theory for it is relatively simple but in practice, it may require some planning due simply to the nature of virtualisation. If you have a firm grasp of the technology, it should be straight forward however. There are essentially three modes for vlan tagging in vSphere: external switch tagging, virtual switch tagging and guest tagging. It is all here. You are correct that you'd need separate vswitches for both the internal and external networks but depending on how you want to manage the internal vlans, you'd want to pick one of the above three methods. I suspect that for the majority of users running pfSense virtualised, you'd want pfSense to manage the vlans so VGT is the preferred route. Your external switch is configured to pass all vlans to the trunk/access port that pfSense is on and esxi will preserve the tagging when it forwards it onto the VM. For the management vlan, even if you have a single vswitch configured to accept all vlans, you can have another switch (on the same vmnic) configured for a single vlan that is also within that other wider vlan group. The usual good practice of moving the native vlan to anything other than the default vlan works in this scenario. A word of advice is that if you plan in future to use vSphere HA, you may want to save yourself the trouble later down the line by setting up your project with HA already up and running rather than migrating everything to Distributed Switches later.

@thewho I installed on 2.7 and upgraded to 2.7.1 and mine appears to remain functional. service qemu-guest-agent start tells me qemu_guest_agent already running? and provides the pid for it. That said .. something is wrong as my memory consumed in the proxmox host has doubled after the move 2.7>2.7.1 (3.2G>7.1G)

@SteveITS said in Update pfsense 23.09 amd64 to ARM: @alvescaio Only Netgate hardware has Arm support (models 1000-3100). Learned something new today. It is a very recent addition, so easy to miss. We only started supporting it since 23.09 released, less than a month ago: https://www.netgate.com/blog/netgate-releases-pfsense-plus-23.09-on-aws-graviton