@pfsense2023

In top it shows high interrupt
fcff96ff-3aae-46e4-bb8d-4a36c88e9f7a-image.png

@faraguti glad you sorted it. Such thing often take longer than they would with the aid of hind sight.

@eiger3970-0
Solved.

@skveen

Your the very first that shows me a system with more RAM as (hard/SSD°VM) disk space ...
I've never seen that before.
Why insisting with such very small disks ?

Does pfSense even fit on a 1 GBytes drive, leaving close to no free space available ?
Not even talking about swap space, which is 'normally' twice the RAM size ....

edit : Google told me you should read this : PfSense Hyper-V .vhdx growing like crazy

@Sergei_Shablovsky said in pfSense 23.09 Intel QAT 4xxx passthrough question:

Right now on USA eBay (where PP able to make chargeback, opposite to many DOA from Chinas sellers) QAT8950 cost USD$50-80

I bought mine over a year ago from a Chinese seller for $37, in fact I bought two because at that price each, why not, while at the time, the QAT 8970 by US sellers priced at $800+ So, priced had fallen...that's good. Both mine are installed in work stations, a Lenovo and a Dell...see sig.

@SolPain

A WAN address is usual DHCP. I guess you want to place pfSense behind Express VPN, so it would be one of 10.184.16.x and you need to select another subnet for pfSense LAN and AD.

Is it a fair assumption that pfSense does not support SRV-IO passthrough? It seems like it used to work. Just wondering if I should continue the effort or give up.

@viragomann Duh, 'obviously'!
Well, thanks, now the Debian KVM can ping the WAN via the KVM router.

@elcalzado said in Can't get VLANs to work in pfsense on proxmox:

Would I create a Linux VLAN in proxmox and call it vmbr2.16 for example? If so would I then go into pfsense and delete my vlan interface I made in there? Or, would I pass in another vmbr2 w tag 16 into the vm and use that as the interface for vlan 16?

All you have to do is to enter the VLAN ID in the virtual NIC settings for pfSense like this:
5efdfd91-4431-4cd5-861d-5de3e4c4b44d-grafik.png
You can do this all in the Proxmox GUI.

In your case it will be 16 for this one. For the next VLAN add an additional network device and state the respective VLAN ID.

In pfSense you would have to remove the VLANs and configure conventional interfaces.

Also do I need to give the Linux VLAN a default gateway, ip, etc?

No. This settings are for Proxmox only and would give it an IP.
Just check "VLAN aware" in the bridge settings.

@aarcane Did you ever find a solution to this problem? I've reproduced it on pfSense 2.7.2 and Proxmox 8.1.4.

@eiger3970-0 Fixed, LAN cable was in, but needed an extra push. Must have been bumped when I removed and added a new USB device.

@DD check this link from redmine, is working for us.

Redmine History

@penne
Looks well.

Did you disable hardware checksum offloading?

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.