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

So now we have another random Netgate bug for which I am thnkful for a fix that I would never have found myself:

https://forum.netgate.com/topic/153708/solved-but-bug-still-present-available-packages-empty

20240824 Changed default Wan IPv6 to have DHCP6 (instead of none) and packages show! No need of IPv6 traffic.

Who could guess this would be left hanging to trap us?

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

@Legal_Brick_527

With two VPN clients running on the same pfSense ?
I didn't really insist when testing (things start to behave very bad).
I'm sure that a first VPN client can used as the 'gateway' for a second VPN client on the same device, but you probably have to set them up the old way : manual config file creation and all that. That's not possible on pfSense.
I hope to be wrong of course.

What was possible :
Setting up a pfSense VPN client to 'some' VPN-ISP, routing all outgoing traffic over this connection, that's classic and works fine.
Then I activated a VPN client on my NAS, used 'another' VPN-ISP, and that connected also "just fine".
Now, I had a tunnel over a tunnel.
As I was using some web https sites to test, I actually had a a tunnel in a tunnel in a tunnel.

Btw : you go beyond what is needed to protect the launch codes of the nukes .... are you sure you need this protection ?