@marcelosb these are local networks - renumber one.

@viragomann
Thanks for the suggestion. I'm using an XCP-NG host. Just found some documentation that explains how to install xen tools and the removal of tx checksum offloading. Not sure which did it, I suspect the latter.

https://docs.xcp-ng.org/guides/pfsense/

Issue resolved.

@Antibiotic All of the PiHoles are on VLAN42. PiHole services VLANS 2,42,100 and 129.

PT_BR:
Hoje (Exatamente agora para ser mais especifico), consegui resolver o problema que me assombrou por longos 8 meses, e vim compartilhar com vocês o que resolveu:

imagem¹ 6b030714-f352-433c-8bbe-f5f714c7081c-image.png
Criei 2 regras de NAT Port Forward escutando na interface PPPoE Server e simplesmente funcionou (era tão simples T-T).

Me sinto tão burro...

EN_US:
Today (Right now to be more specific), I managed to solve the problem that haunted me for 8 long months, and I came to share with you what solved it:

image¹

I created 2 NAT Port Forward rules listening on the PPPoE Server interface and it simply worked (it was so simple T-T).

I feel so dumb...

You should be able to get that from your manufacturer's docs. Since it's on the far side of the FW, it's no different than going to any external website. My last 2 modems, Motorola and Netgear) used 192.168.100.1 while I use 192.168.0.0/24 inside.

@jkiel
Yes, but this is only true for NAT reflection. And as I stated in my first sentence above, NAT reflection just reflects the NAT rule to other interfaces. So the proxy is only applied to traffic coming from OTHER interface, not from WAN, where the real NAT rule is defined on.

Traffic forwarded from WAN still keeps its origin source address.
Simply sniff the traffic on the LAN to verify this.

@eeebbune
Port forwarding is typically used for inbound connections
natting is for outbound

It is not clear what the issue is and what is inside HM_PBX_DESK_phone too

@viragomann

Hi again,

I believe I have made it work now. The only thing I did was to push a route from the server side, like
push "route 192.168.123.0 255.255.255.0" (this is a route to a LAN on the VPN server). I am not using this subnet in any way seen from the client side, so kind of strange that just adding a route made the NAT setup work.

That made the client side use the ovpnc interface instead of lo0. Now both the internal monitor pings and the DNS lookups via the ovpnc interface translates correctly.

Thanks again for the assistance, viragomann.

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