@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:

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

@bearhntr
That's basically a Proxmox Topic. Maybe its firewall only allow access to the former interface.

As I understand it - in order for any other VMs (currently only pfSense on here - until I figure this out) need to use the same vmbrXX that pfSense is using for LAN in order to get an address? Is this accurate?

Yes, if you set an IP on the bridge, I'd expect, that you can access the GUI using it.

However, to have IPs on multiple interfaces within the same subnet, is not a good idea at all. So you should remove the other and maybe it needs to be rebooted then.