@nerdile In case anyone is struggling with a similar issue in the future, one thing I noticed that could indicate this issue is that the firewall shows allowing the SYN packets from the LAN client but never shows any responses later. (You have to turn on logging of your default allow rule to see this traffic flowing.)

@noreast-it said in Not able to open Odoo required ports and allow through the firewall.:

a virtual IoT box running on a windows server 2019 VM in order to connect to all needed printers via ethernet.

Well any firewall rules you need to do would be on that VM host then, not on pfsense.

But nowhere do I see any talk of opening a port forward in your firewall allowing any ports inbound unsolicited from the internet. You clearly see the virtual iot box in their system.. Why it can't print would be on that box or their system.. Has nothing to do with firewall rules or port forwarding on pfsense.

Very helpful, thank you.

@sogorman well you don't really need to do a 1:1, you could do simple port forwards for the ports you want vs all of them ;)

So you want this fqdn to resolve to the internal IP? Just setup a host override so your local.redacted.com resolves to the 192.168.0.7

What your seeing now is WAD, Works As Designed.

@paulvanduijn I have the exact same problem on two pfSense VMs running in KVM with VirtIO drivers. So far I cannot find a solution online. I tried to Disable hardware checksum offload and Disable hardware TCP segmentation offload and it did NOT work. My download speed is 500-600 Mbits but upload speed is 0.1 Mbit.

This happens on the latest pfSense 2.7.2 and pfSense Plus 23.09.1

As in, Halt System. Then push the power button to turn back on.

In reviewing the same concern in opnsense, it appears commits were made some 3 years back to enable this exact functionality.

https://github.com/opnsense/core/issues/5005

Any chance of this getting ported to pfsense?

@viragomann Thanks to your explanations, I understood and cleaned all pfSense rules and configs!
Thanks you so much Viragomann !

@Anaerin
It looks like the issue is Wireguard. Disabling Wireguard, removing it's interface, tunnel and peers removes the rules.

Quite why Wireguard is grabbing the wrong subnet for the VPN subnet and redirecting it to the local net is an issue.

@ruqen001

Show also the related WAN firewall rules.

@Vinibo1

I'm going to assume your servers have already been mapped on the NAT.

Here's my two cents beyond that:

Your cisco set up was masking the internal IPs using "overload". This function automatically performs a port address translation and you'll have to manually input that into pfsense if you want to specify the external IP used by your servers when reaching out over the WAN.

You can do this in firewall>NAT>outbound. Select "Manual Outbound NAT rule generation." Create a rule similar to the Cisco setup:
Interface: WAN
Source: 192.168.0.0/24 (DMZ network) or 192.168.1.0/24 (LAN network)
Translation Address: Use the WAN address or specify the public IPs.

@Gertjan thanks - that damn curiosity cat was really meowing at me about this one ;) clawing at back of my brain as well - what would you want use such an alias for?? hahahha

Since your devices are isolated for security reasons, it could be blocking the communication needed for those alerts. You might need to tweak your firewall settings or NAT rules. If the issue persists, it could be worth exploring how systems like Vivint security system handle network segmentation while still delivering reliable push notifications.