@FoolCoconut said in Wireguard + Port Forwarding = Return Traffic exiting through WAN???:

Holy f**k.

The problem was an any/any rule in the Wireguard unasigned tunnel firewall rule list. Even though the AirVPN WG interface was assigned, group rules are evaluated first...

Hope this helps someone else as well.

@FoolCoconut THANK you. ive been trying to figure this out for a very long time.

@The-Party-of-Hell-No said in Outgoing LAN only OK to ISP GW:

Wondering about NAT outbound and whether you have rules allowing LAN subnet out other gateways/interfaces?

Reply

It’s definitely worth checking if you have NAT outbound rules set up to allow traffic from your LAN subnet to go out through the other gateways or interfaces.

@Stefanix said in Modem O&M behind NAT reachable, but why??:

Private IP destinations shouldn't traverse outgoing NAT, right?

Why do you think that.

@cedrictang
I am assuming the tunnel is working. Have you assigned an interface to the tunnel (there is a gateway)?
NAT outbound manual rule - direct (give permission) the VLAN out the VPN tunnel.
Firewall - rules - (the VLAN Interface) create a pass rule just above the all rule or edit the all rule by opening the advanced menu and at the bottom change the gateway to the IPSEC gateway. If you don't edit the all rule you should disable it. I tend to leave things alone as much as possible so I can later understand the changes I made.
I think this will get you there.

@dguy pretty sure any $20 dumb switch would solve your problem if your just short a port..

Connect the current cable that runs to pfs1 wan to a dumb switch, also connect pfs2 wan port to this switch.. That would be a much better solution than trying to setup a bridge and then have to firewall on the bridge, etc. etc.

I would do that vs complicating my main pfsense setup..

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